Parti e 1 

Introduction a l’algorithmique 


L’algorithmique est un terme d’origine arabe, comme algebre, amiral ou zenith. Ce n’est pas une excuse pour 
massacrer son orthographe, ou sa prononciation. 

Ainsi, I’algo n’est pas « rythmique », a la difference du bon ro =^\ roll. L’algo n’est pas non plus « I’agglo ». 
Alors, ne confondez pas I’algorithmique avec I’agglo rythmique, qui consiste a poser des parpaings en cadence. 


1. Qu’est-ce que l’algomachin ? 

Avez-vous deja ouvert un livre de recettes de cuisine ? Avez vous deja dechiffre un mode d’emploi traduit 
directement du coreen pour faire fonctionner un magnetoscope ou un repondeur telephonique reticent ? Si oui, 
sans le savoir, vous avez deja execute des algorithmes. 

Plus fort : avez-vous deja indique un chemin a un touriste egare ? Avez vous fait chercher un objet a quelqu’un 
par telephone ? Ecrit une lettre anonyme stipulant comment proceder a une remise de rancon ? Si oui, vous avez 
deja fabrique - et fait executer - des algorithmes. 

Comme quoi, I’algorithmique n’est pas un savoir esoterique reserve a quelques rares inities touches par la grace 
divine, mais une aptitude partagee par la totalite de I’humanite. Done, pas d ’excuses... 

Un algorithme, e’est une suite d’instructions, qui une fois executee correctement, conduit a un resultat 
donne. Si I’algorithme est juste, le resultat est le resultat voulu, et le touriste se retrouve la ou il voulait aller. Si 
I’algorithme est faux, le resultat est, disons, aleatoire, et decidement, cette saloperie de repondeur ne veut rien 
savoir. 

Completons toutefois cette definition. Apres tout, en effet, si I’algorithme, comme on vient de le dire, n’est 
qu’une suite d’instructions menant celui qui I’execute a resoudre un probleme, pourquoi ne pas donner comme 
instruction unique : « resous le probleme », et laisser I’interlocuteur se debrouiller avec ca ? A ce tarif, n’importe 
qui serait champion d’algorithmique sans faire aucun effort. Pas de ca Lisette, ce serait trop facile. 

Le malheur (ou le bonheur, tout depend du point de vue) est que justement, si le touriste vous demande son 
chemin, e’est qu’il ne le connait pas. Done, si on n’est pas un goujat integral, il ne sert a rien de lui dire de le 
trouver tout seul. De meme les modes d’emploi contiennent generalement (mais pas toujours) un peu plus 
d’informations que « debrouillez vous pour que ca marche ». 

Pour fonctionner, un algorithme doit done contenir uniquement des instructions comprehensibles par celui 
qui devra I’executer. C’est d’ailleurs I’un des points delicats pour les redacteurs de modes d’emploi : les 
references culturelles, ou lexicales, des utilisateurs, etant variables, un meme mode d’emploi peut etre tres clair 
pour certains et parfaitement abscons pour d’autres. 

En informatique, heureusement, il n’y a pas ce probleme : les choses auxquelles ont doit donner des instructions 
sont les ordinateurs, et ceux-ci ont le bon gout d’etre tous strictement aussi idiots les uns que les autres. 


2. Faut-il etre matheux pour etre bon en algorithmique ? 

Je consacre quelques lignes a cette question, car cette opinion aussi fortement affirmee que faiblement fondee 
sert regulierement d’excuse : « moi, de toute facon, je suis mauvais(e) en algo, j’ai jamais rien pige aux maths ». 
Faut-il etre « bon en maths » pour expliquer correctement son chemin a quelqu’un ? Je vous laisse juge. 

La maitrise de I’algorithmique requiert deux qualites, tres complementaires d’ailleurs : 


• il faut avoir une certaine in^jion, car aucune recette ne permet de savoir a priori quelles 
instructions permettront d’obtenir leresultat voulu. C’est la, si I’on y tient, qu’intervient la forme 
« d’intelligence » requise pour I’algorithmique. Alors, c’est certain, il y a des gens qui possedent au depart 
davantage cette intuition que les autres. Cependant, et j’insiste sur ce point, les reflexes, cela s’acquiert. 
Et ce qu’on appelle I’intuition n’est finalement que de I’experience tellement repetee que le 
raisonnement, au depart laborieux, finit par devenir « spontane ». 


• il faut etre methodique et rigoureux. En effet, chaque fois qu’on ecrit une serie d’instructions 
qu’on croit justes, il faut systematiquement se mettre mentalement a la place de la machine qui va les 
executer, arme d'un papier et d'un crayon, afin de verifier si le resultat obtenu est bien celui que I’on 
voulait. Cette operation ne requiert pas la moindre once d’intelligence. Mais elle reste neanmoins 
indispensable, si I’on ne veut pas ecrire a I’aveuglette. 

Et petit a petit, a force de pratique, vous verrez que vous pourrez faire de plus en plus souvent I’economie de 
cette derniere etape : I’experience fera que vous « verrez » le resultat produit par vos instructions, au fur et a 
mesure que vous les ecrirez. Naturellement, cet apprentissage est long, et demande des heures de travail patient. 
Aussi, dans un premier temps, evitez de sauter les etapes : la verification methodique, pas a pas, de chacun de 
vos algorithmes represente plus de la moitie du travail a accomplir... et le gage de vos progres. 

3. L’ADN, les Shadoks, et les ordinateurs 

Quel rapport me direz-vous ? Eh bien le point commun est : quatre mots de vocabulaire. 

L’univers lexical Shadok, c’est bien connu, se limite aux termes « Ga », « Bu », « Zo », et « Meu ». Ce qui leur a 
tout de meme permis de formuler quelques fortes maximes, telles que : « Mieux vaut pomper et qu’il ne se passe 
rien, plutot qu’arreter de pomper et risquer qu’il se passe quelque chose de pire » (pour d’autres fortes maximes 
Shadok, n’hesitez pas a visiter leur site Internet, il y en a toute une collection qui vaut le detour). 

L’ADN, qui est en quelque sorte le programme genetique, I’algorithme a la base de construction des etres 
vivants, est une chaTne construite a partir de quatre elements invariables. Ce n’est que le nombre de ces elements, 
ainsi que I’ordre dans lequel ils sont arranges, qui vont determiner si on obtient une puce ou un elephant. Et tous 
autant que nous sommes, splendides reussites de la Nature, avons ete construits par un « programme » constitue 
uniquement de ces quatre briques, ce qui devrait nous inciter a la modestie. 

Enfin, les ordinateurs, quels qu’ils soient, ne sont fondamentalement capables de comprendre que quatre 
categories d'ordres (en programmation, on n'emploiera pas le terme d'ordre, mais plutot celui destructions). Ces 
quatre families destructions sont : 

• I’affectation de variables 

• la lecture / ecriture 

• les tests 

• les boucles 

Un algorithme informatique se ramene done toujours au bout du compte a la combinaison de ces quatre petites 
briques de base. Il peut y en avoir quelques unes, quelques dizaines, et jusqu’a plusieurs centaines de milliers dans 
certains programmes de gestion. Rassurez-vous, dans le cadre de ce cours, nous n’irons pas jusque la (cependant, 
la taille d’un algorithme ne conditionne pas en soi sa complexite : de longs algorithmes peuvent etre finalement 
assez simples, et de petits tres compliques). 

4. Algorithmique et programmation 

Pourquoi apprendre I’algorithmique pour apprendre a programmer? En quoi a-t-on besoin d’un langage special, 
distinct des langages de programmation comprehensibles par les ordinateurs ? 

Parce que I’algorithmique exprime les instructions resolvant un probleme donne independamment des 
particularites de tel ou tel langage. Pour prendre une image, si un programme etait une dissertation, 
I’algorithmique serait le plan, une fois mis de cote la redaction et I’orthographe. Or, vous savez qu’il vaut mieux 
faire d’abord le plan et rediger ensuite que I’inverse... 

Apprendre I’algorithmique, c’est apprendre a manier la structure logique d’un programme informatique. Cette 
dimension est presente quelle que soit le langage de programmation ; mais lorsqu’on programme dans un langage 
(en C, en Visual Basic, etc.) on doit en plus se colleter les problemes de syntaxe, ou de types d’instructions, 



propres a ce langage. Apprendre I’algorithmique de maniere separee, c’est done serier les difficultes pour mieux 
les vaincre. 

A cela, il faut ajouter que des generations de programmeurs, souvent autodidactes (mais pas toujours, helas !), 
ayant directement appris a programmer dans tel ou tel langage, ne font pas mentalement clairement la difference 
entre ce qui releve de la structure logique generate de toute programmation (les regies fondamentales de 
I’algorithmique) et ce qui releve du langage particular qu’ils ont appris. Ces programmeurs, non seulement ont 
beaucoup plus de mal a passer ensuite a un langage different, mais encore ecrivent bien souvent des programmes 
qui meme s’ils sont justes, restent laborieux. Car on n ’ignore pas impunement les regies fondamentales de 
I’algorithmique... Alors, autant I’apprendre en tant que telle ! 

Bon, maintenant que j’ai bien fait I’article pour vendre ma marchandise, on va presque pouvoir passer au vif du 
sujet... 

5. AVEC QUEUES CONVENTIONS ECRIT-ON UN ALGORITHME ? 

Historiquement, plusieurs types de notations ont represente des algorithmes. 

II y a eu notamment une representation graphique, avec des carres, des losanges, etc. qu’on appelait des 
organigrammes. Aujourd’hui, cette representation est quasiment abandonnee, pour deux raisons. D’abord, parce 
que des que 1’algorithme commence a grossir un peu, ce n’est plus pratique du tout du tout. Ensuite parce que 
cette representation favorise le glissement vers un certain type de programmation, dite non structuree (nous 
definirons ce terme plus tard), que I’on tente au contraire d’eviter. 

C’est pourquoi on utilise generalement une serie de conventions appelee « pseudo-code », qui ressemble a un 
langage de programmation authentique dont on aurait evacue la plupart des problemes de syntaxe. Ce pseudo-code 
est susceptible de varier legerement d’un livre (ou d’un enseignant) a un autre. C’est bien normal : le pseudo- 
code, encore une fois, est purement conventionnel ; aucune machine n’est censee le reconnaitre. Done, chaque 
cuisinier peut faire sa sauce a sa guise, avec ses petites epices bien a lui, sans que cela prete a consequence. 

Comme je n’ai pas moins de petites manies que la majorite de mes semblables, le pseudo-code que vous 
decouvrirez dans les pages qui suivent possede quelques specificites mineures qui ne doivent qu’a mes nevroses 
personnelles. 

Rassurez-vous cependant, celles-ci restent dans les limites tout a fait acceptables. 

En tout cas, personnellement, je les accepte tres bien. 



Parti e 2 

Lecture et Ecriture 

1 . DE QUOI PARLE-T-ON ? 

Trifouiller des variables en memoire vive par un chouette programme, c’est vrai que c’est tres marrant, et 
d’ailleurs on a tous bien rigole au chapitre precedent. Cela dit, a la fin de la foire, on peut tout de meme se 
demander a quoi ca sert. 

En effet. Imaginons que nous ayons fait un programme pour calculer le carre d’un nombre, mettons 12. Si on a 
fait au plus simple, on a ecrit un true du genre : 

Variable A en Numerique 
Debut 
A - 12A2 
Fin 

D’une part, ce programme nous donne le carre de 12. C’est tres gentil a lui. Mais si I’on veut le carre d’un autre 
nombre que 12, il faut reecrire le programme. Bof. 

D’autre part, le resultat est indubitablement calcule par la machine. Mais elle le garde soigneusement pour elle, 
et le pauvre utilisateur qui fait executer ce programme, lui, ne saura jamais quel est le carre de 12. Re-bof. 

C’est pourquoi, heureusement, il existe des d’instructions pour permettre a la machine de dialoguer avec 
I’utilisateur (et Lycee de Versailles, eut ajoute I’estime Pierre Dac, qui en precurseur meconnu de I’algorithmique, 
affirmait tout aussi profondement que « rien ne sert de penser, il faut reflechir avant »). 

Dans un sens, ces instructions permettent a I’utilisateur de rentrer des valeurs au clavier pour qu’elles soient 
utilisees par le programme. Cette operation est la lecture. 

Dans I’autre sens, d’autres instructions permettent au programme de communiquer des valeurs a I’utilisateur en 
les affichant a I’ecran. Cette operation est I’ecriture. 

Remarque essentielle : A premiere vue, on peut avoir I’impression que les informaticiens etaient beurres 
comme des petits lus lorsqu’ils ont baptise ces operations ; puisque quand I’utilisateur doit ecrire au clavier, on 
appelle ca la lecture, et quand il doit lire sur I’ecran on appelle ca I’ecriture. Mais avant d’agonir d’insultes une 
digne corporation, il faut reflechir un peu plus loin. Un algorithme, c’est une suite d’instructions qui programme la 
machine, pas I’utilisateur ! Done quand on dit a la machine de lire une valeur, cela implique que I’utilisateur va 
devoir ecrire cette valeur. Et quand on demande a la machine d’ecrire une valeur, c’est pour que I’utilisateur 
puisse la lire. Lecture et ecriture sont done des termes qui comme toujours en programmation, doivent etre 
compris du point de vue de la machine qui sera chargee de les executer. Et la, tout devient parfaitement logique. 

Et toe. 

2. Les instructions de lecture et d’ecriture 


Tout betement, pour que I’utilisateur entre la (nouvelle) valeur de Titi, on mettra : 
Lire Titi 



Des lors, aussitot que la touche Entree (Enter) a ete frappee, I’execution reprend. Dans le sens inverse, pour 
ecrire quelque chose a I’ecran, c’est aussi simple que : 

Ecrire Toto 


Avant de Lire une variable, il est tres fortement conseille d’ecrire des libelles a I’ecran, afin de prevenir 
I’utilisateur de ce qu’il doit frapper (sinon, le pauvre utilisateur passe son temps a se demander ce que I’ordinateur 
attend de lui... et c’est tres desagreable !) : 

Ecrire "Entrez votre nom : " 

Lire NomFamille 

Lecture et Ecriture sont des instructions algorithmiques qui ne presentent pas de difficultes particulieres, une 
fois qu’on a bien assimile ce probleme du sens du dialogue (homme — > machine, ou machine <— homme). 

Et ca y est, vous savez d’ores et deja sur cette question tout ce qu’il y a a savoir... 



Parti e 3 
Les T ests 

1. DE QUOI S’AGIT-IL ? 

Reprenons le cas de notre « programmation algorithmique du touriste egare ». Normalement, I’algorithme 
ressemblera a quelque chose comme : « Allez tout droit jusqu’au prochain carre four, puis prenez a droite et 
ensuite la deuxieme a gauche, et vous y etes ». 

Mais en cas de doute legitime de votre part, cela pourrait devenir : « Allez tout droit jusqu’au prochain 
carrefour et la regardez a droite. Si la rue est autorisee a la circulation, alors prenez la et ensuite c’est la 
deuxieme a gauche. Mais si en revanche elle est en sens interdit, alors continuez jusqu’a la prochaine a droite, 
prenez celle-la, et ensuite la premiere a droite ». 

Ce deuxieme algorithme a ceci de superieur au premier qu’il prevoit, en fonction d’une situation pouvant se 
presenter de deux facons differentes, deux facons differentes d’agir. Cela suppose que I’interlocuteur (le touriste) 
sache analyser la condition que nous avons fixee a son comportement (« la rue est-elle en sens interdit ? ») pour 
effectuer la serie d ’actions correspondante. 

Eh bien, croyez le ou non, mais les ordinateurs possedent cette aptitude, sans laquelle d’ailleurs nous aurions 
bien du mal a les programmer. Nous allons done pouvoir parler a notre ordinateur comme a notre touriste, et lui 
donner des series d ’instructions a effectuer selon que la situation se presente d’une maniere ou d’une autre. Cette 
structure logique repond au doux nom de test. Toutefois, ceux qui tiennent absolument a briller en societe 
parleront egalement de structure alternative. 

2. Structure d’un test 

II n’y a que deux formes possibles pour un test ; la premiere est la plus simple, la seconde la plus complexe. 

Si booleen Alors 
Instructi ons 

Fi nsi 

Si booleen Alors 
Instructions 1 

si non 

Instructions 2 

Finsi 

Ceci appelle quelques explications. 

Un booleen est une expression dont la valeur est VRAI ou FAUX. Cela peut done etre (il n’y a que deux 
possibilites) : 


• une variable (ou une expression) de type booleen 

• une condition 

Nous reviendrons dans quelques instants sur ce qu’est une condition en informatique. 

Toujours est-il que la structure d’un test est relativement claire. Dans la forme la plus simple, arrive a la 
premiere ligne (Si... Alors) la machine examine la valeur du booleen. Si ce booleen a pour valeur VRAI, elle execute 
la serie destructions. Cette serie destructions peut etre tres breve comme tres longue, cela n’a aucune 
importance. En revanche, dans le cas ou le booleen est faux, I'ordinateur saute directement aux instructions situees 
apres le FinSi. 

Dans le cas de la structure complete, e'est a peine plus complique. Dans le cas ou le booleen est VRAI, et apres 
avoir execute la serie destructions 1, au moment ou elle arrive au mot « Sinon », la machine saute directement a 
la premiere instruction situee apres le « Finsi ». De meme, au cas ou le booleen a comme valeur « Faux », la 
machine saute directement a la premiere ligne situee apres le « Sinon » et execute I’ensemble des « instructions 
2 ». Dans tous les cas, les instructions situees juste apres le FinSi seront executees normalement. 


En fait, la forme simplifiee correspond au cas ou I’une des deux « branches » du Si est vide. Des lors, plutot 
qu’ecrire « sinon ne rien faire du tout », il est plus simple de ne rien ecrire. Et laisser un Si... complet, avec une 


des deux branches vides, est considere comme une tres grosse maladresse pour un programmeur, meme si cela ne 


constitue pas a proprement parler une faute. 

Exprime sous forme de pseudo-code, la programmation de notre touriste de tout a I’heure donnerait done 


quelque chose du genre : 


Allez tout droit jusqu 
Si la rue a droite est 
Tournez a droite 
Avancez 

Prenez la deuxieme a 

Si non 

Continuez jusqu’a la 
Prenez cette rue 
Prenez la premiere a 

Fi nsi 


au prochain carrefour 
autorisee a la circulation Alors 

gauche 

prochaine rue a droite 
droi te 


3. Qu’est ce qu’une condition ? 



Cette definition est essentielle ! Elle signifie qu’une condition est composee de trois elements : 


• une valeur 

• un operateur de comparaison 

• une autre valeur 

Les valeurs peuvent etre a priori de n’importe quel type (numeriques, caracteres...). Mais si I’on veut que la 
comparaison ait un sens, il faut que les deux valeurs de la comparaison soient du meme type ! 

Les operateurs de comparaison sont : 

• egal a... 

• different de... 

• strictement plus petit que... 

• strictement plus grand que... 

• plus petit ou egal a... 

• plus grand ou egal a... 

L’ensemble des trois elements constituant la condition constitue done, si I’on veut, une affirmation, qui a un 
moment donne est VRAIE ou FAUSSE. 

A noter que ces operateurs de comparaison peuvent tout a fait s’employer avec des caracteres. Ceux-ci sont 
codes par la machine dans I’ordre alphabetique (rappelez vous le code ASCII vu dans le preambule), les majuscules 
etant systematiquement placees avant les minuscules. Ainsi on a : 

“t” < “w ” VRAI 

“Maman” > “Papa“ FAUX 

“maman” > “Papa” VRAI 

Remarque tres importante 


En formulant une condition dans un algorithme, il faut se mefier comme de la peste de certains raccourcis du 
langage courant, ou de certaines notations valides en mathematiques, mais qui menent a des non-sens 
informatiques. Prenons par exemple la phrase « Toto est compris entre 5 et 8 ». On peut etre tente de la traduire 
par : 5 < Toto < 8 



Or, une telle expression, qui a du sens en francais, comme en mathematiques, ne veut rien dire en 
programmation. En effet, elle comprend deux operateurs de comparaison, soit un de trap, et trois valeurs, soit la 
aussi une de trap. On va voir dans un instant comment traduire convenablement une telle condition. 

4. Conditions composees 

Certains problemes exigent parfois de formuler des conditions qui ne peuvent pas etre exprimees sous la forme 
simple exposee ci-dessus. Reprenons le cas « Toto est inclus entre 5 et 8 ». En fait cette phrase cache non une, 
mais deux conditions. Car elle revient a dire que « Toto est superieur a 5 et Toto est inferieur a 8 ». Ilya done 
bien la deux conditions, reliees par ce qu’on appelle un operateur logique, le mot ET. 

Comme on I’a evoque plus haut, I’informatique met a notre disposition quatre operateurs logiques : ET, OU, 
NON, et XOR. 


• Le ET a le meme sens en informatique que dans le langage courant. Pour que "Conditionl ET 
Condition2" soit VRAI, il faut imperativement que Conditionl soit VRAI et que Condition2 soit VRAI. Dans 
tous les autres cas, "Condition 1 et Condition2" sera faux. 

• II faut se mefier un peu plus du OU. Pour que "Conditionl OU Condition2" soit VRAI, il suffit que 
Conditionl soit VRAIE ou que Condition2 soit VRAIE. Le point important est que si Conditionl est VRAIE et 
que Condition2 est VRAIE aussi, Conditionl OU Condition2 reste VRAIE. Le OU informatique ne veut done 
pas dire « ou bien » 

• Le XOR (ou OU exclusif) fonctionne de la maniere suivante. Pour que "Conditionl XOR Condition2" 
soit VRAI, il faut que soit Conditionl soit VRAI, soit que Condition2 soit VRAI. Si toutes les deux sont 
fausses, ou que toutes les deux sont VRAI, alors le resultat global est considere comme FAUX. Le XOR est 
done I'equivalent du "ou bien" du langage courant. 

J’insiste toutefois sur le fait que le XOR est une rarete, dont il n’est pas strictement indispensable de 
s’encombrer en programmation. 

• Enfin, le NON inverse une condition : N0N(Condition1 )est VRAI si Conditionl est FAUX, et il sera 
FAUX si Conditionl est VRAI. C'est I'equivalent pour les booleens du signe "moins" que I'on place devant les 
nombres. 

Alors, vous vous demandez peut-etre a quoi sert ce NON. Apres tout, plutot qu’ecrire NON(Prix > 20), il 
serait plus simple d’ecrire tout bonnement Prix=<20. Dans ce cas precis, c’est evident qu’on se complique 
inutilement la vie avec le NON. Mais si le NON n'est jamais indispensable, il y a tout de meme des situations 
dans lesquelles il s'avere bien utile. 

On represente frequemment tout ceci dans des tables de verite (Cl et C2 representent deux conditions, et on 
envisage a chaque fois les quatre cas possibles) 


Cl et C2 

C2 Vrai 

C2 Faux 

Cl Vrai 

Vrai 

Faux 

Cl Faux 

Faux 

Faux 

Cl ou C2 

C2 Vrai 

C2 Faux 

Cl Vrai 

Vrai 

Vrai 

Cl Faux 

Vrai 

Faux 

Cl xor C2 

C2 Vrai 

C2 Faux 

Cl Vrai 

Faux 

Vrai 

Cl Faux 

Vrai 

Faux 


Non Cl 





LE GAG DE LA JOURNEE... 


Cl Vrai 
Cl Faux 


Faux 

Vrai 


...Consiste a formuler dans un test une condition qui ne pourra jamais etre vraie, ou jamais etre fausse. Si ce 
n’est pas fait expres, c’est assez rigolo. Si c’est fait expres, c’est encore plus drole, car une condition dont on sait 
d’avance qu’elle sera toujours fausse n’est pas une condition. Dans tous les cas, cela veut dire qu’on a ecrit un test 
qui n’en est pas un, et qui fonctionne comme s’il n’y en avait pas. 

Cela peut etre par exemple : Si Toto < 10 ET Toto > 15 Alors... (il est tres difficile de trouver un nombre qui soit a la 
fois inferieur a 10 et superieur a 15 !) 

Bon, ca, c’est un motif immediat pour payer une tournee generate, et je sens qu’on ne restera pas longtemps le 
gosier sec. 

5. Tests imbriques 

Graphiquement, on peut tres facilement representer un SI comme un aiguillage de chemin de fer (ou un 
aiguillage de train electrique, c’est moins lourd a porter). Un SI ouvre done deux voies, correspondant a deux 
traitements differents. Mais il y a des tas de situations ou deux voies ne suffisent pas. Par exemple, un programme 
devant donner I’etat de I’eau selon sa temperature doit pouvoir choisir entre trois reponses possibles (solide, 
liquide ou gazeuse). 

Une premiere solution serait la suivante : 

Variable Temp en Entier 
Debut 

Ecrire "Entrez la temperature de l’eau 
Lire Temp 

Si Temp =< 0 Alors 

Ecrire "c’est de la glace" 

Fi nSi 

Si Temp > 0 Et Temp < 100 Alors 
Ecrire "C’est du liquide" 

Finsi 

Si Temp > 100 Alors 

Ecrire "c’est de la vapeur" 

Fi nsi 
Fin 

Vous constaterez que c’est un peu laborieux. Les conditions se ressemblent plus ou moins, et surtout on oblige 
la machine a examiner trois tests successifs alors que tous portent sur une meme chose, la temperature de I'eau (la 
valeur de la variable Temp). Il serait ainsi bien plus rationnel d’imbriquer les tests de cette maniere : 
variable Temp en Entier 
Debut 

Ecrire "Entrez la temperature de l’eau 
Lire Temp 

Si Temp =< 0 Alors 

Ecrire "C’est de la glace" 

Si non 

Si Temp < 100 Alors 

Ecrire "c’est du liquide" 

Si non 

Ecrire "c’est de la vapeur" 

Fi nsi 
Finsi 
Fin 

Nous avons fait des economies : au lieu de devoir taper trois conditions, dont une composee, nous n’avons plus 
que deux conditions simples. Mais aussi, et surtout, nous avons fait des economies sur le temps d ’execution de 



I’ordinateur. Si la temperature est inferieure a zero, celui-ci ecrit dorenavant « C’est de la glace » et passe 
directement a la fin, sans etre ralenti par I’examen d’autres possibility (qui sont forcement fausses). 

Cette deuxieme version n’est done pas seulement plus simple a ecrire et plus lisible, elle est egalement plus 
performante a l ’execution. 

Les structures de tests imbriques sont done un outil indispensable a la simplification et a ^optimisation des 
algorithmes. 

6. De l’aiguillage a la gare de tri 

« J'ai fame ferroviaire : je regarde passer les vaches » (Leo Ferre) 

Cette citation n’apporte peut-etre pas grand chose a cet expose, mais je I’aime bien, alors e’etait le moment 
ou jamais. 

En effet, dans un programme, une structure SI peut etre facilement comparee a un aiguillage de train. La voie 
principale se separe en deux, le train devant rouler ou sur I’une, ou sur I’autre, et les deux voies se rejoignant tot 
ou tard pour ne plus en former qu’une seule, lors du FinSi. On peut schematiser cela ainsi : 


instructions 1 



Mais dans certains cas, ce ne sont pas deux voies qu’il nous faut, mais trois, ou meme plus. Dans le cas de I’etat 
de I’eau, il nous faut trois voies pour notre « train », puisque I’eau peut etre solide, liquide ou gazeuse. Alors, nous 
n’avons pas eu le choix : pour deux voies, il nous fallait un aiguillage, pour trois voies il nous en faut deux, 
imbriques I’un dans I’autre. 

Cette structure (telle que nous I’avons programmee a la page precedente) devrait etre schematisee comme 
suit : 


instructions 1 



Soyons bien clairs : cette structure est la seule possible du point de vue logique (meme si on peut toujours 
mettre le bas en haut et le haut en bas). Mais du point de vue de I’ecriture, le pseudo-code algorithmique admet 
une simplification supplemental. Ainsi, il est possible (mais non obligatoire, que I’algorithme initial : 
variable Temp en Entier 
Debut 

Ecrire "Entrez la temperature de l’eau 
Lire Temp 

Si Temp =< 0 Alors 

Ecrire "C'est de la glace" 

Si non 

Si Temp < 100 Alors 

Ecrire "C’est du liquide" 

Si non 

Ecrire "C’est de la vapeur" 

Fi nsi 


Finsi 

Fin 

devienne : 

variable Temp en Entier 
Debut 

Ecrire "Entrez la temperature de l’eau 
Lire Temp 

Si Temp =< 0 Alors 

Ecrire "c’est de la glace" 

SinonSi Temp < 100 Alors 
Ecrire "c’est du liquide" 

Si non 


Ecrire "c’est de la vapeur" 

Fi nsi 
Fin 



Le SinonSi permet en quelque sorte de creer (en realite, de simuler) des aiguillages a plus de deux branches. On 
peut ainsi enchainer les SinonSi les uns derriere les autres pour simuler un aiguillage a autant de branches que I’on 
souhaite. 


7. Variables Booleennes 

Jusqu’ici, pour ecrire nos des tests, nous avons utilise uniquement des conditions. Mais vous vous rappelez qu’il 
existe un type de variables (les booleennes) susceptibles de Stocker les valeurs VRAI ou FAUX. En fait, on peut done 
entrer des conditions dans ces variables, et tester ensuite la valeur de ces variables. 

Reprenons I’exemple de I’eau. On pourrait le reecrire ainsi : 

Variable Temp en Entier 
variables a, b en Booleen 
Debut 

Ecrire "Entrez la temperature de l’eau 
Lire Temp 
A «- Temp =< 0 
B <- Temp < 100 

Si A Alors 

Ecrire "C’est de la glace" 

SinonSi b Alors 

Ecrire "C’est du liquide" 

Si non 

Ecrire "C’est de la vapeur" 

Finsi 

Fin 

A priori, cette technique ne presente guere d’interet : on a alourdi plutot qu’allege I’algorithme de depart, en 
ayant recours a deux variables supplementaires. 


• Mais souvenons-nous : une variable booleenne n’a besoin que d’un seul bit pour etre stockee. De ce 
point de vue, I’alourdissement n’est done pas considerable. 

• dans certains cas, notamment celui de conditions composees tres lourdes (avec plein de ET et de 
OU tout partout) cette technique peut faciliter le travail du programmeur, en ameliorant nettement la 
lisibilite de I’algorithme. Les variables booleennes peuvent egalement s’averer tres utiles pour servir de 
flag, technique dont on reparlera plus loin (rassurez-vous, rien a voir avec le flagrant delit des policiers). 



Parti e 4 

Encore de la Logique 

1 . Faut-il METTRE UN ET ? Faut-il METTRE UN OU ? 

Une remarque pour commencer : dans le cas de conditions composees, les parentheses jouent un role 
fondamental. 

variables a, b, c, d, e en Booleen 
Variable X en Entier 
Debut 
Lire X 

A <- X > 12 
B <- X > 2 
C <- X < 6 
D <- (A ET B) OU C 
E <- A ET (B OU C) 

Ecrire D, E 
Fin 

Si X = 3, alors on remarque que D sera VRAI alors que E sera FAUX. 

S’il n’y a dans une condition que des ET, ou que des OU, en revanche, les parentheses ne changent strictement 
rien. 



On en arrive a une autre propriete des ET et des OU, bien plus interessante. 

Spontanement, on pense souvent que ET et OU s’excluent mutuellement, au sens ou un probleme donne 
s’exprime soit avec un ET, soit avec un OU. Pourtant, ce n’est pas si evident. 

Quand faut-il ouvrir la fenetre de la salle ? Uniquement si les conditions I’imposent, a savoir : 

Si il fait trop chaud ET il ne pleut pas Alors 
Ouvri r 1 a fenetre 
si non 

Fermer la fenetre 

Finsi 

Cette petite regie pourrait tout aussi bien etre formulee comme suit : 

Si il ne fait pas trop chaud OU il pleut Alors 
Fermer la fenetre 

Si non 

Ouvri r 1 a fenetre 


Fi nsi 

Ces deux formulations sont strictement equivalentes. Ce qui nous amene a la conclusion suivante : 



Ceci est moins surprenant qu’il n’y parait au premier abord. Jetez pour vous en convaincre un oeil sur les tables 
de verite, et vous noterez la symetrie entre celle du ET et celle du OU. Dans les deux tables, il y a trois cas sur 
quatre qui menent a un resultat, et un sur quatre qui mene au resultat inverse. Alors, rien d’etonnant a ce qu’une 
situation qui s’exprime avec une des tables (un des operateurs logiques) puisse tout aussi bien etre exprimee avec 
I’autre table (I’autre operateur logique). Toute I’astuce consiste a savoir effectuer correctement ce passage. 

Bien sur, on ne peut pas se contenter de remplacer purement et simplement les ET par des OU ; ce serait un peu 
facile. La regie d’equivalence est la suivante (on peut la verifier sur I’exemple de la fenetre) : 

Si a et b Alors 
instructions 1 
Si non 

Instructions 2 

Fi nsi 




equivaut a : 


si NON A OU NON B Alors 
instructions 2 

Si non 

Instructions 1 

Fi nsi 


Cette regie porte le nom de transformation de Morgan, du nom du mathematicien anglais qui I'a formulee. 


2. Au-dela de la logique : le style 

Ce titre un peu provocateur (mais neanmoins justifie) a pour but d’attirer maintenant votre attention sur un fait 
fondamental en algorithmique, fait que plusieurs remarques precedentes ont deja du vous faire soupconner : il n’y 
a jamais une seule maniere juste de traiter les structures alternatives. Et plus generalement, il n’y a jamais une 
seule maniere juste de traiter un probleme. Entre les differentes possibilites, qui ne sont parfois pas meilleures les 
unes que les autres, le choix est une affaire de style. 

C’est pour cela qu’avec I’habitude, on reconnait le style d’un programmeur aussi surement que s’il s’agissait de 
style litteraire. 

Reprenons nos operateurs de comparaison maintenant familiers, le ET et le OU. En fait, on s’apercoit que I’on 
pourrait tout a fait s’en passer ! Par exemple, pour reprendre I’exemple de la fenetre de la salle : 

Si il fait trop chaud ET il ne pleut pas Alors 
Ouvri r 1 a fenetre 

Si non 

Fermer la fenetre 

Fi nsi 

Possede un parfait equivalent algorithmique sous la forme de : 

Si il fait trop chaud Alors 
Si il ne pleut pas Alors 
Ouvri r 1 a fenetre 

Si non 

Fermer la fenetre 

Fi nsi 
Si non 

Fermer la fenetre 

Finsi 

Dans cette derniere formulation, nous n’avons plus recours a une condition composee (mais au prix d’un test 
imbrique supplementaire) 


Et comme tout ce qui s’exprime par un ET peut aussi etre exprime par un OU, nous en concluons que le OU peut 
egalement etre remplace par un test imbrique supplementaire. On peut ainsi poser cette regie stylistique 
generate : 



Si vous avez compris ce qui precede, et que I'exercice de la date ne vous pose plus aucun probleme, alors vous 
savez tout ce qu'il y a a savoir sur les tests pour affronter n'importe quelle situation. Non, ce n'est pas de la 
demagogie ! 


Malheureusement, nous ne sommes pas tout a fait au bout de nos peines ; il reste une derniere structure logique 
a examiner, et pas des moindres... 



Parti e 5 
Les Boucles 


Et ca y est, on y est, on est arrives, la voila, c’est Broadway, la quatrieme et derniere structure : ca est les 
boucles. Si vous voulez epater vos amis, vous pouvez egalement parler de structures repetitives, voire carrement 
de structures iteratives. Ca calme, hein ? Bon, vous faites ce que vous voulez, ici on est entre nous, on parlera de 
boucles. 

Les boucles, c'est generalement le point douloureux de I'apprenti programmeur. C'est la que ca coince, car 
autant il est assez facile de comprendre comment fonctionnent les boucles, autant il est souvent long d'acquerir les 
reflexes qui permettent de les elaborer judicieusement pour traiter un probleme donne. 

On peut dire en fait que les boucles constituent la seule vraie structure logique caracteristique de la 
programmation. Si vous avez utilise un tableur comme Excel, par exemple, vous avez sans doute pu manier des 
choses equivalentes aux variables (les cellules, les formules) et aux tests (la fonction SI...). Mais les boucles, ca, ca 
n'a aucun equivalent. Cela n'existe que dans les langages de programmation proprement dits. 

Le maniement des boucles, s'il ne differencie certes pas I'homme de la bete (il ne faut tout de meme pas 
exagerer), est tout de meme ce qui separe en informatique le programmeur de I'utilisateur, meme averti. 

Alors, a vos futures - et inevitables - difficultes sur le sujet, il y a trois remedes : de la rigueur, de la patience, 
et encore de la rigueur ! 

1 . A QUOI CELA SERT-IL DONC ? 

Prenons le cas d’une saisie au clavier (une lecture), ou par exemple, le programme pose une question a laquelle 
I’utilisateur doit repondre par 0 (Oui) ou N (Non). Mais tot ou tard, I’utilisateur, facetieux ou maladroit, risque de 
taper autre chose que la reponse attendue. Des lors, le programme peut planter soit par une erreur d ’execution 
(parce que le type de reponse ne correspond pas au type de la variable attendu) soit par une erreur fonctionnelle 
(il se deroule normalement jusqu’au bout, mais en produisant des resultats fantaisistes). 

Alors, dans tout programme un tant soit peu serieux, on met en place ce qu’on appelle un controle de saisie, 
afin de verifier que les donnees entrees au clavier correspondent bien a celles attendues par I’algorithme. 

A vue de nez, on pourrait essayer avec un SI. Voyons voir ce que ca donne : 

Variable Rep en Caractere 
Debut 

Ecrire "voulez vous un cafe ? (0/N)" 

Li re Rep 

Si Rep <> "0" et Rep <> "N" Alors 

Ecrire "Saisie erronnee. Recommencez" 

Lire Rep 
Fin Si 
Fin 

C’est impeccable. Du moins tant que I’utilisateur a le bon gout de ne se tromper qu’une seule fois, et d’entrer 
une valeur correcte a la deuxieme demande. Si I’on veut egalement betonner en cas de deuxieme erreur, il 
faudrait rajouter un SI. Et ainsi de suite, on peut rajouter des centaines de SI, et ecrire un algorithme aussi lourd 
qu’une blague des Grosses Tetes, on n’en sortira pas, il y aura toujours moyen qu’un acharne flanque le programme 
par terre. 

La solution consistant a aligner des SI... en pagaille est done une impasse. La seule issue est done de flanquer 
une structure de boucle, qui se presente ainsi : 

TantQue booleen 

Instructi ons 

Fi nTantQue 


Le principe est simple : le programme arrive sur la ligne du TantQue. II examine alors la valeur du booleen (qui, 
je le rappelle, peut etre une variable booleenne ou, plus frequemment, une condition). Si cette valeur est VRAI, le 
programme execute les instructions qui suivent, jusqu’a ce qu’il rencontre la ligne FinTantQue. II retourne ensuite 
sur la ligne du TantQue, procede au meme examen, et ainsi de suite. Le manege enchante ne s’arrete que lorsque 
le booleen prend la valeur FAUX. 

Illustration avec notre probleme de controle de saisie. Une premiere approximation de la solution consiste a 
ecrire : 

Variable Rep en Caractere 
Debut 

Ecrire "voulez vous un cafe ? (0/N)" 

TantQue Rep <> "0" et Rep <> "N" 

Lire Rep 
Fi nTantQue 
Fin 

La, on a le squelette de I’algorithme correct. Mais de meme qu’un squelette ne suffit pas pour avoir un etre 
vivant viable, il va nous falloir ajouter quelques muscles et organes sur cet algorithme pour qu’il fonctionne 
correctement. 

Son principal defaut est de provoquer une erreur a chaque execution. En effet, I’expression booleenne qui 
figure apres le TantQue interroge la valeur de la variable Rep. Malheureusement, cette variable, si elle a ete 
declaree, n’a pas ete affectee avant I’entree dans la boucle. On teste done une variable qui n’a pas de valeur, ce 
qui provoque une erreur et I’arret immediat de I’execution. Pour eviter ceci, on n’a pas le choix : il faut que la 
variable Rep ait deja ete affectee avant qu’on en arrive au premier tour de boucle. Pour cela, on peut faire une 
premiere lecture de Rep avant la boucle. Dans ce cas, celle-ci ne servira qu’en cas de mauvaise saisie lors de cette 
premiere lecture. L’algorithme devient alors : 
variable Rep en Caractere 
Debut 

Ecrire "voulez vous un cafe ? (0/N)" 

Li re Rep 

TantQue Rep <> "0" et Rep <> "N" 

Lire Rep 
Fi nTantQue 
Fin 

Une autre possibility, frequemment employee, consiste a ne pas lire, mais a affecter arbitrairement la variable 
avant la boucle. Arbitrairement ? Pas tout a fait, puisque cette affectation doit avoir pour resultat de provoquer 
I’entree obligatoire dans la boucle. L’affectation doit done faire en sorte que le booleen soit mis a VRAI pour 
declencher le premier tour de la boucle. Dans notre exemple, on peut done affecter Rep avec n’importe quelle 
valeur, hormis « 0 » et « N » : car dans ce cas, I’execution sauterait la boucle, et Rep ne serait pas du tout lue au 
clavier. Cela donnera par exemple : 
variable Rep en Caractere 
Debut 
Rep <- "X" 

Ecrire "voulez vous un cafe ? (0 /n)" 

TantQue Rep <> "0" et Rep <> "N" 

Lire Rep 
Fi nTantQue 
Fin 

Cette maniere de proceder est a connaitre, car elle est employee tres frequemment. 

Il faut remarquer que les deux solutions (lecture initiate de Rep en dehors de la boucle ou affectation de Rep) 
rendent toutes deux I’algorithme satisfaisant, mais presentent une difference assez importante dans leur structure 
logique. 


En effet, si I’on choisit d’effectuer une lecture prealable de Rep, la boucle ulterieure sera executee uniquement 
dans I’hypothese d’une mauvaise saisie initiale. Si I’utilisateur saisit une valeur correcte a la premiere demande de 
Rep, I’algorithme passera sur la boucle sans entrer dedans. 

En revanche, avec la deuxieme solution (celle d’une affectation prealable de Rep), I’entree de la boucle est 
forcee, et I’execution de celle-ci, au moins une fois, est rendue obligatoire a chaque execution du programme. Du 
point de vue de I’utilisateur, cette difference est tout a fait mineure ; et a la limite, il ne la remarquera meme 


pas. Mais du point de vue du programmeur, il importe de bien comprendre que les cheminements des instructions 
ne seront pas les memes dans un cas et dans I’autre. 

Pour terminer, remarquons que nous pourrions peaufiner nos solutions en ajoutant des affichages de libelles qui 
font encore un peu defaut. Ainsi, si I’on est un programmeur zele, la premiere solution (celle qui inclut deux 


lectures de Rep, une en dehors de la boucle, I’autre a I’interieur) pourrait devenir : 


Variable Rep en Caractere 
Debut 

Ecrire "voulez vous un cafe ? (O/N)" 

Li re Rep 

TantQue Rep <> "0" et Rep <> "N" 

Ecrire "vous devez repondre par 0 ou N. 

Lire Rep 
Fi nTantQue 

Ecrire "Saisie acceptee" 

Fin 


Recommencez" 


Quant a la deuxieme solution, elle pourra devenir : 
variable Rep en Caractere 
Debut 

Rep <- "X" 

Ecrire "voulez vous un cafe ? (O/N)" 

TantQue Rep <> "0" et Rep <> "N" 

Lire Rep 

Si Rep <> "0" et Rep <> "N" Alors 
Ecrire "Saisie Erronee, Recommencez" 

Fi nSi 

Fi nTantQue 
Fin 


Le Gag De La Journee 

C’est d’ecrire une structure TantQue dans laquelle le booleen n’est jamais VRAI. Le programme ne rentre alors 
jamais dans la superbe boucle sur laquelle vous avez tant sue ! 

Mais la faute symetrique est au moins aussi desopilante. 

Elle consiste a ecrire une boucle dans laquelle le booleen ne devient jamais FAUX. L’ordinateur tourne alors dans la 
boucle comme un derate et n’en sort plus. Seule solution, quitter le programme avec un demonte-pneu ou un baton 
de dynamite. La « boucle infinie » est une des hantises les plus redoutees des programmeurs. C’est un peu comme 
le verre baveur, le poil a gratter ou le bleu de methylene : c’est ecule, mais ca fait toujours rire. 

Cette faute de programmation grossiere - mais frequente - ne manquera pas d’egayer I’ambiance collective de 
cette formation... et accessoirement d’etancher la soif proverbiale de vos enseignants. 

Bon, eh bien vous allez pouvoir faire de chouettes algorithmes, deja rien qu’avec ca... 


2. Boucler en comptant, ou compter en bouclant 

Dans le dernier exercice, vous avez remarque qu’une boucle pouvait etre utilisee pour augmenter la valeur 
d’une variable. Cette utilisation des boucles est tres frequente, et dans ce cas, il arrive tres souvent qu’on ait 
besoin d’effectuer un nombre determine de passages. Or, a priori, notre structure TantQue ne sait pas a I’avance 
combien de tours de boucle elle va effectuer (puisque le nombre de tours depend de la valeur d’un booleen). 

C’est pourquoi une autre structure de boucle est a notre disposition : 

Variable True en Entier 
Debut 


True <- 0 

TantQue True < 15 
True «- True + 1 

Ecrire "Passage numero : ", True 

Fi nTantQue 
Fin 

Equivaut a : 

variable True en Entier 
Debut 

Pour True «- 1 a 15 

Ecrire "Passage numero : ", True 
True Suivant 
Fin 

Insistons : la structure « Pour ... Suivant » n’est pas du tout indispensable ; on pourrait fort bien programmer 
toutes les situations de boucle uniquement avec un « Tant Que ». Le seul interet du « Pour » est d’epargner un peu 
de fatigue au programmeur, en lui evitant de gerer lui-meme la progression de la variable qui lui sert de compteur 
(on parle decrementation, encore un mot qui fera forte impression sur votre entourage). 

Dit d’une autre maniere, la structure « Pour ... Suivant » est un cas particulier de TantQue : celui ou le 
programmeur peut denombrer a I’avance le nombre de tours de boucles necessaires. 

II faut noter que dans une structure « Pour ... Suivant », la progression du compteur est laissee a votre libre 
disposition. Dans la plupart des cas, on a besoin d’une variable qui augmente de 1 a chaque tour de boucle. On ne 
precise alors rien a I’instruction « Pour » ; celle-ci, par defaut, comprend qu’il va falloir proceder a cette 
incrementation de 1 a chaque passage, en commencant par la premiere valeur et en terminant par la deuxieme. 

Mais si vous souhaitez une progression plus speciale, de 2 en 2, ou de 3 en 3, ou en arriere, de -1 en -1 , ou de - 
10 en -10, ce n’est pas un probleme : il suffira de le preciser a votre instruction « Pour >> en lui rajoutant le mot 
« Pas » et la valeur de ce pas (Le « pas » dont nous parlons, e’est le « pas » du marcheur, « step » en anglais). 

Naturellement, quand on stipule un pas negatif dans une boucle, la valeur initiate du compteur doit etre 
superieure a sa valeur finale si I’on veut que la boucle tourne ! Dans le cas contraire, on aura simplement ecrit une 
boucle dans laquelle le programme ne rentrera jamais. 

Nous pouvons done maintenant donner la formulation generate d’une structure « Pour ». Sa syntaxe generate 
est : 

Pour Compteur <- initial a Final Pas valeurDuPas 
Instructi ons 
Compteur suivant 

Les structures TantQue sont employees dans les situations ou I’on doit proceder a un traitement systematique 
sur les elements d’un ensemble dont on ne connait pas d’avance la quantite, comme par exemple : 

• le controle d’une saisie 

• la gestion des tours d’un jeu (tant que la partie n’est pas finie, on recommence) 

• la lecture des enregistrements d’un fichier de taille inconnue(cf. Partie 9) 

Les structures Pour sont employees dans les situations ou I’on doit proceder a un traitement systematique sur 
les elements d’un ensemble dont le programmeur connait d’avance la quantite. 

Nous verrons dans les chapitres suivants des series d’elements appeles tableaux (parties 7 et 8) et chaines de 
caracteres (partie 9). Selon les cas, le balayage systematique des elements de ces series pourra etre effectue par 
un Pour ou par un TantQue : tout depend si la quantite d’elements a balayer (done le nombre de tours de boucles 
necessaires) peut etre denombree a I’avance par le programmeur ou non. 


3. Des boucles dans des boucles 

(« TOUT EST DANS TOUT... ET RECIPROQUEMENT ») 

On rigole, on rigole ! 

De meme que les poupees russes contiennent d’autres poupees russes, de meme qu’une structure SI ... ALORS 
peut contenir d’autres structures SI ... ALORS, une boucle peut tout a fait contenir d’autres boucles. Y a pas de 
raison. 

Variables True, Trac en Entier 
Debut 

Pour True «- 1 a 15 

Ecrire "il est passe par ici" 

Pour Trac «- 1 a 6 

Ecrire "il repassera par la" 

Trac Suivant 
True Suivant 
Fin 

Dans cet exemple, le programme ecrira une fois "il est passe par ici" puis six fois de suite "il repassera par la", et 
ceci quinze fois en tout. A la fin, il y aura done eu 15 x 6 = 90 passages dans la deuxieme boucle (celle du milieu), 
done 90 ecritures a I’ecran du message « il repassera par la ». Notez la difference marquante avec cette structure : 
Variables True, Trac en Entier 
Debut 

Pour True «- 1 a 15 

Ecrire "Il est passe par ici" 

True Suivant 
Pour Trac «- 1 a 6 

Ecrire "Il repassera par la" 

Trac Suivant 
Fin 

Ici, il y aura quinze ecritures consecutives de "il est passe par ici", puis six ecritures consecutives de "il repassera 
par la", et ce sera tout. 

Des boucles peuvent done etre imbriquees (cas n°1) ou successives (cas n°2). Cependant, elles ne peuvent 
jamais, au grand jamais, etre croisees. Cela n’aurait aucun sens logique, et de plus, bien peu de langages vous 
autoriseraient ne serait-ce qu’a ecrire cette structure aberrante. 

Variables True, Trac en Entier 
Pour True <- ... 
i nstructi ons 
Pour Trac «- ... 
i nstructi ons 
True Suivant 
i nstructi ons 
Trac Suivant 

Pourquoi imbriquer des boucles ? Pour la meme raison qu’on imbrique des tests. La traduction en bon francais 
d’un test, e’est un « cas ». Eh bien un « cas » (par exemple, « est-ce un homme ou une femme ? ») peut tres bien 
se subdiviser en d’autres cas (« a-t-il plus ou moins de 18 ans ? »). 

De meme, une boucle, e’est un traitement systematique, un examen d’une serie d’elements un par un (par 
exemple, « prenons tous les employes de I’entreprise un par un »). Eh bien, on peut imaginer que pour chaque 
element ainsi considere (pour chaque employe), on doive proceder a un examen systematique d’autre chose 
(« prenons chacune des commandes que cet employe a traitees »). Voila un exemple typique de boucles 
imbriquees : on devra programmer une boucle principale (celle qui prend les employes un par un) et a I’interieur, 
une boucle secondaire (celle qui prend les commandes de cet employe une par une). 

Dans la pratique de la programmation, la maitrise des boucles imbriquees est necessaire, meme si elle n’est pas 
suffisante. Tout le contraire d’Alain Delon, en quelque sorte. 




4. Et encore une betise a ne pas faire ! 

Examinons I’algorithme suivant : 
variable True en Entier 
Debut 

Pour True <- 1 a 15 
True <- True * 2 

Ecrire "Passage numero : ", True 
True Suivant 
Fin 

Vous remarquerez que nous faisons ici gerer « en double » la variable True, ces deux gestions etant 
contradictoires. D’une part, la ligne 
Pour... 

augmente la valeur de True de 1 a chaque passage. D’autre part la ligne 
True <- True * 2 

double la valeur de True a chaque passage. II va sans dire que de telles manipulations perturbent completement 
le deroulement normal de la boucle, et sont causes, sinon de plantages, tout au moins d ’executions erratiques. 

Le Gag De La Journee 

II consiste done a manipuler, au sein d’une boucle Pour, la variable qui sert de compteur a cette boucle. Cette 
technique est a proscrire absolument... sauf bien sur, si vous cherchez un pretexte pour regaler tout le monde au 
bistrot. 

Mais dans ce cas, n’ayez aucune inhibition, proposez-le directement, pas besoin de pretexte. 


Parti e 6 
Les Tableaux 

Bonne nouvelle ! Je vous avais annonce qu’il y a avait en tout et pour tout quatre structures logiques dans la 
programmation. Eh bien, ca y est, on les a toutes passees en revue. 

Mauvaise nouvelle, il vous reste tout de meme quelques petites choses a apprendre... 

1 . Utilite des tableaux 

Imaginons que dans un programme, nous ayons besoin simultanement de 12 valeurs (parexemple, des notes 
pour calculer une moyenne). Evidemment, la seule solution dont nous disposons a I’heure actuelle consiste a 
declarer douze variables, appelees par exemple Notea, Noteb, Notec, etc. Bien sur, on peut opter pour une 
notation un peu simplifiee, parexemple N1, N2, N3, etc. Mais cela ne change pas fondamentalement notre 
probleme, car arrive au calcul, et apres une succession de douze instructions « Lire » distinctes, cela donnera 
obligatoirement une atrocite du genre : 

Moy <- (N1 +n2+n3+n4+n5+n6+n7+n8+n9+n10+n11+n12)/12 

Ouf ! C’est tout de meme bigrement laborieux. Et pour un peu que nous soyons dans un programme de gestion 
avec quelques centaines ou quelques milliers de valeurs a traiter, alors la c’est le suicide direct. 

Cerise sur le gateau, si en plus on est dans une situation on I’on ne peut pas savoir d’avance combien il y aura 
de valeurs a traiter, la on est carrement cuits. 

C’est pourquoi la programmation nous permet de rassembler toutes ces variables en une seule, au sein de 
laquelle chaque valeur sera designee par un numero. En bon francais, cela donnerait done quelque chose du genre 
« la note numero 1 », « la note numero 2 », « la note numero 8 ». C’est largement plus pratique, vous vous en 
doutez. 



2. Notation et utilisation algorithmique 

Dans notre exemple, nous creerons done un tableau appele Note. Chaque note individuelle (chaque element du 
tableau Note) sera done designee Note(O), Note(1), etc. Eh oui, attention, les indices des tableaux commencent 
generalement a 0, et non a 1 . 

Un tableau doit etre declare comme tel, en precisant le nombre et le type de valeurs qu’il contiendra (la 
declaration des tableaux est susceptible de varier d'un langage a I'autre. Certains langages reclament le nombre 
d'elements, d'autre le plus grand indice... C'est done une affaire de conventions). 

En nous calquant sur les choix les plus frequents dans les langages de programmations, nous deciderons ici 
arbitrairement et une bonne fois pour toutes que : 

• les "cases" sont numerotees a partir de zero, autrement dit que le plus petit indice est zero. 

• lors de la declaration d'un tableau, on precise la plus grande valeur de I'indice (differente, done, du 
nombre de cases du tableau, puisque si on veut 12 emplacements, le plus grand indice sera 11). Au debut, 
ca deroute, mais vous verrez, avec le temps, on se fait a tout, meme au pire. 

Tableau Note (11) en Entier 

On peut creer des tableaux contenant des variables de tous types : tableaux de numeriques, bien sur, mais aussi 
tableaux de caracteres, tableaux de booleens, tableaux de tout ce qui existe dans un langage donne comme type 
de variables. Par contre, hormis dans quelques rares langages, on ne peut pas faire un mixage de types differents 
de valeurs au sein d’un meme tableau. 



L’enorme avantage des tableaux, c’est qu’on va pouvoir les traiter en faisant des boucles. Par exemple, pour 
effectuer notre calcul de moyenne, cela donnera par exemple : 

Tableau Note (11) en Numerique 
Variables Moy, Som en Numerique 
Debut 

Pour i *- 0 a 11 

Ecrire "Entrez la note n°", i 
Lire Note(i) 
i Suivant 

Som <- 0 

Pour i *- 0 a 11 

Som <- Som + Note(i) 
i Suivant 
Moy <- Som / 12 
Fin 

NB : On a fait deux boucles successives pour plus de Lisibi lite, mais on aurait tout aussi bien pu n’en ecrire 
qu’une seule dans laquelle on aurait tout fait d’un seul coup. 

Remarque generale : I’indice qui sert a designer les elements d’un tableau peut etre exprime directement 
comme un nombre en clair, mais il peut etre aussi une variable, ou une expression calculee. 

Dans un tableau, la valeur d’un indice doit toujours : 

• etre egale au moins a 0 (dans quelques rares langages, le premier element d’un tableau porte 
I’indice 1). Mais comme je I'ai deja ecrit plus haut, nous avons choisi ici de commencer la numerotation des 
indices a zero, comme c’est le cas en langage C et en Visual Basic. Done attention, Truc(6) est le septieme 
element du tableau True ! 

• etre un nombre entier Quel que soit le langage, I’element Truc(3,1416) n’existe jamais. 

• etre inferieure ou egale au nombre d’elements du tableau (moins 1 , si I’on commence la 
numerotation a zero). Si le tableau Bidule a ete declare comme ayant 25 elements, la presence dans une 
ligne, sous une forme ou sous une autre, de Bidule(32) declenchera automatiquement une erreur. 

Je le re-re-repete, si I’on est dans un langage ou les indices commencent a zero, il faut en tenir compte a la 
declaration : 

Tableau Note(13) en Numerique 

...creera un tableau de 14 elements, le plus petit indice etant 0 et le plus grand 13. 

LE GAG DE LA JOURNEE 

Il consiste a confondre, dans sa tete et / ou dans un algorithme, I’indice d’un element d’un tableau avec le 
contenu de cet element. La troisieme maison de la rue n’a pas forcement trois habitants, et la vingtieme vingt 
habitants. En notation algorithmique, il n’y a aucun rapport entre i et truc(i). 

Hola, Tavernier, prepare la cervoise ! 

3. Tableaux dynamiques 

Il arrive frequemment que I’on ne connaisse pas a I’avance le nombre d’elements que devra comporter un 
tableau. Bien sur, une solution consisterait a declarer un tableau gigantesque (10 000 elements, pourquoi pas, au 
diable les varices) pour etre sur que « ca rentre ». Mais d’une part, on n’en sera jamais parfaitement sur, d’autre 
part, en raison de I’immensite de la place memoire reservee - et la plupart du temps non utilisee, c’est un gachis 
prejudiciable a la rapidite, voire a la viabilite, de notre algorithme. 

Aussi, pour parer a ce genre de situation, a-t-on la possibility de declarer le tableau sans preciser au depart son 
nombre d’elements. Ce n’est que dans un second temps, au cours du programme, que I’on va fixer ce nombre via 
une instruction de redimensionnement : Redim. 

Notez que tant qu’on n’a pas precise le nombre d’elements d’un tableau, d’une maniere ou d’une autre, ce 
tableau est inutilisable. 


Exemple : on veut faire saisir des notes pour un calcul de moyenne, mais on ne sait pas combien il y aura de 
notes a saisir. Le debut de I’algorithme sera quelque chose du genre : 

Tableau Notes O en Numerique 
Variable nb en Numerique 
Debut 

Ecrire "Combien y a-t-il de notes a saisir ?" 

Li re nb 

Redim Notes(nb-l) 

Cette technique n’a rien de sorcier, mais elle fait partie de I’arsenal de base de la programmation en gestion. 


Parti e 7 

Techniques Rusees 

Une fois n’est pas coutume, ce chapitre n’a pas pour but de presenter un nouveau type de donnees, un nouveau 
jeu d’instructions, ou que sais-je encore. 

Son propos est de detainer quelques techniques de programmation qui possedent deux grands points communs : 

• leur connaissance est parfaitement indispensable 

• elles sont un rien finaudes 

Et que valent quelques kilos d’aspirine, compares a I’ineffable bonheur procure par la comprehension supreme 
des arcanes de I’algorithmique ? Hein ? 

1 . Tri d’un tableau : le tri par SELECTION 

Premiere de ces ruses de sioux, et par ailleurs tarte a la creme absolue du programmeur, done : le tri de 
tableau. 

Combien de fois au cours d’une carriere (brillante) de developpeur a-t-on besoin de ranger des valeurs dans un 
ordre donne ? C’est inimaginable. Aussi, plutot qu’avoir a reinventer a chaque fois la roue, le fusil a tirer dans les 
coins, le fil a couper le roquefort et la poudre a maquiller, vaut-il mieux avoir assimile une ou deux techniques 
solidement eprouvees, meme si elles paraissent un peu ardues au depart. 

II existe plusieurs strategies possibles pour trier les elements d’un tableau ; nous en verrons deux : le tri par 
selection, et le tri a bulles. Champagne ! 

Commencons par le tri par selection. 

Admettons que le but de la manoeuvre soit de trier un tableau de 12 elements dans I’ordre croissant. La 
technique du tri par selection est la suivante : on met en bonne position I’element numero 1, e’est-a-dire le plus 
petit. Puis en met en bonne position I’element suivant. Et ainsi de suite jusqu’au dernier. Par exemple, si I’on part 
de : 


45 

122 

12 

3 

21 

78 

64 

53 

89 

28 

84 

46 


On commence par rechercher, parmi les 12 valeurs, quel est le plus petit element , et ou il se trouve. On 
I’identifie en quatrieme position (c’est le nombre 3), et on I’echange alors avec le premier element (le nombre 45). 
Le tableau devient ainsi : 


3 

122 

12 

45 

21 

78 

64 

53 

89 

28 

84 

46 


On recommence a chercher le plus petit element, mais cette fois, seulement a partir du deuxieme (puisque le 
premier est maintenant correct, on n’y touche plus). On le trouve en troisieme position (c’est le nombre 12). On 
echange done le deuxieme avec le troisieme : 


3 

12 

122 

45 

21 

78 

64 

53 

89 

28 

84 

46 


On recommence a chercher le plus petit element a partir du troisieme (puisque les deux premiers sont 
maintenant bien places), et on le place correctement, en I’echangeant, ce qui donnera in fine : 





3 

12 

21 

45 

122 

78 

64 

53 

89 

28 

84 

46 


Et cetera, et cetera, jusqu’a I’avant dernier. 

En bon francais, nous pourrions decrire le processus de la maniere suivante : 

• Boucle principale : prenons comme point de depart le premier element, puis le second, etc, jusqu’a 
I’avant dernier. 

• Boucle secondaire : a partir de ce point de depart mouvant, recherchons jusqu’a la fin du tableau 
quel et le plus petit element. Une fois que nous I’avons trouve, nous I’echangeons avec le point de depart. 

Cela s’ecrit : 

boucle principale : le point de depart se decal e a chaque tour 
Pour i <- 0 a 10 

on considere provi soi rement que t(i) est le plus petit element 
posmini «- i 

on examine tous les elements suivants 
Pour j <- i + 1 a 11 

Si t(j) < t(posmini) Alors 
posmi ni *- j 

Finsi 
j suivant 

A cet endroit, on sait maintenant ou est le plus petit element, il ne reste plus qu'a effectuer 
la permutation, 
temp «- t(posmini) 
t (posmini) <- t(i) 
t(i) «- temp 

On a place correctement l'element numero i, on passe a present au suivant. 

i suivant 


2. Un exemple de flag : LA recherche dans UN tableau 

Nous allons maintenant nous interesser au maniement habile d’une variable booleenne : la technique dite du 
« flag ». 

Le flag, en anglais, est un petit drapeau, qui va rester baisse aussi longtemps que I’evenement attendu ne se 
produit pas. Et, aussitot que cet evenement a lieu, le petit drapeau se leve (la variable booleenne change de 
valeur). Ainsi, la valeur finale de la variable booleenne permet au programmeur de savoir si I’evenement a eu lieu 
ou non. 

Tout ceci peut vous sembler un peu fumeux, mais cela devrait s’eclairer a I’aide d’un exemple extremement 
frequent : la recherche de I’occurrence d’une valeur dans un tableau. On en profitera au passage pour corriger une 
erreur particulierement frequente chez le programmeur debutant. 

Soit un tableau comportant, disons, 20 valeurs. L’on doit ecrire un algorithme saisissant un nombre au clavier, 
et qui informe I’utilisateur de la presence ou de I’absence de la valeur saisie dans le tableau. 

La premiere etape, evidente, consiste a ecrire les instructions de lecture / ecriture, et la boucle - car il y en a 
manifestement une - de parcours du tableau : 

Tableau Tab(19) en Numerique 
variable N en Numerique 
Debut 

Ecrire "Entrez la valeur a rechercher" 

Li re N 

Pour i <- 0 a 19 
??? 



i suivant 
Fin 

II nous reste a combler les points ^interrogation de la boucle Pour. Evidemment, il va falloir comparer N a 
chaque element du tableau : si les deux valeurs sont egales, alors bingo, N fait partie du tableau. Cela va se 
traduire, bien entendu, par un Si ... Alors ... Sinon. Et voila le programmeur raisonnant hativement qui se vautre en 
ecrivant : 

Tableau Tab(19) en Numerique 
Variable N en Numerique 
Debut 

Ecrire "Entrez la valeur a rechercher" 

Li re N 

Pour i <- 0 a 19 

Si N = Tab(i) Alors 

Ecrire "N fait partie du tableau" 

sinon 

Ecrire "N ne fait pas partie du tableau" 

Finsi 
i suivant 
Fin 

Et patatras, cet algorithme est une veritable catastrophe. 

II suffit d'ailleurs de le faire tourner mentalement pour s'en rend re compte. De deux choses I'une : ou bien la 
valeur N figure dans le tableau, ou bien elle n'y figure pas. Mais dans tous les cas, I'algorithme ne doit produire 
qu'une seule reponse, quel que soit le nombre d'elements que compte le tableau. Or, I'algorithme ci-dessus 
envoie a I'ecran autant de messages qu'il y a de valeurs dans le tableau, en ^occurrence pas moins de 20 ! 

II y a done une erreur manifeste de conception : I'ecriture du message ne peut se trouver a I'interieur de la 
boucle : elle doit figurer a I'exterieur. On sait si la valeur etait dans le tableau ou non uniquement lorsque le 
balayage du tableau est entierement accompli. 

Nous reecrivons done cet algorithme en placant le test apres la boucle. Faute de mieux, on se contentera de 
faire dependre pour le moment la reponse d'une variable booleenne que nous appellerons Trouve. 

Tableau Tab(19) en Numerique 
variable N en Numerique 
Debut 

Ecrire "Entrez la valeur a rechercher" 

Li re N 

Pour i <- 0 a 19 
??? 

i suivant 
Si Trouve Alors 

Ecrire "N fait partie du tableau" 

si non 

Ecrire "N ne fait pas partie du tableau" 

Fi nSi 
Fi n 

II ne nous reste plus qu'a gerer la variable Trouve. Ceci se fait en deux etapes. 



• un test figurant dans la boucle, indiquant lorsque la variable Trouve doit devenir vraie (a savoir, 
lorsque la valeur N est rencontree dans le tableau). Et attention : le test est asymetrique. II ne comporte 
pas de "sinon". On reviendra la dessus dans un instant. 

• last, but not least, I'affectation par defaut de la variable Trouve, dont la valeur de depart doit etre 
evidemment Faux. 

Au total, I'algorithme complet - et juste ! - donne : 

Tableau Tab(19) en Numerique 
variable N en Numerique 


Debut 

Ecrire "Entrez la valeur a rechercher" 

Li re N 

Trouve <- Faux 
Pour i <- 0 a 19 

Si N = Tab(i) Alors 
Trouve <- vrai 

Fi nSi 
i suivant 
Si Trouve Alors 

Ecrire "N fait parti e du tableau" 

Si non 

Ecrire "N ne fait pas parti e du tableau" 

Fi nSi 
Fin 

Meditons un peu sur cette affaire. 

La difficulty est de comprendre que dans une recherche, le probleme ne se formule pas de la meme maniere 
selon qu'on le prend par un bout ou par un autre. On peut resumer I'affaire ainsi : il suffit que N soit egal a une 
seule valeur de Tab pour qu'elle fasse partie du tableau. En revanche, il faut qu'elle soit differente de toutes 
les valeurs de Tab pour qu'elle n'en fasse pas partie. 

Voila la raison qui nous oblige a passer par une variable booleenne , un « drapeau » qui peut se lever, mais 
jamais se rabaisser. Et cette technique de flag (que nous pourrions elegamment surnommer « gestion asymetrique 
de variable booleenne ») doit etre mise en oeuvre chaque fois que I’on se trouve devant pareille situation. 

Autrement dit, connaitre ce type de raisonnement est indispensable, et savoir le reproduire a bon escient ne 
Test pas moins. 

3. TRI DE TABLEAU + FLAG = TRI A BULLES 

Et maintenant, nous en arrivons a la formule magique : tri de tableau + flag = tri a bulles. 

L’idee de depart du tri a bulles consiste a se dire qu’un tableau trie en ordre croissant, c’est un tableau dans 
lequel tout element est plus petit que celui qui le suit. Cette constatation percutante semble digne de M. de 
Lapalisse, un ancien voisin a moi. Mais elle est plus profonde - et plus utile - qu’elle n’en a I’air. 

En effet, prenons chaque element d’un tableau, et comparons-le avec I’element qui le suit. Si I’ordre n’est pas 
bon, on permute ces deux elements. Et on recommence jusqu’a ce que Ton n’ait plus aucune permutation a 
effectuer. Les elements les plus grands « remontent » ainsi peu a peu vers les dernieres places, ce qui explique la 
charmante denomination de « tri a bulle ». Comme quoi Calgorithmique n’exclut pas un minimum syndical de sens 
poetique. 

En quoi le tri a bulles implique-t-il I’uti Lisation d’un flag ? Eh bien, par ce qu’on ne sait jamais par avance 
combien de remontees de bulles on doit effectuer. En fait, tout ce qu’on peut dire, c’est qu’on devra effectuer le 
tri jusqu’a ce qu’il n’y ait plus d’elements qui soient mal classes. Ceci est typiquement un cas de question 
« asymetrique » : il suffit que deux elements soient mal classes pour qu’un tableau ne soit pas trie. En revanche, il 
faut que tous les elements soient bien ranges pour que le tableau soit trie. 

Nous baptiserons le flag Yapermute, car cette variable booleenne va nous indiquer si nous venons ou non de 
proceder a une permutation au cours du dernier balayage du tableau (dans le cas contraire, c’est signe que le 
tableau est trie, et done qu’on peut arreter la machine a bulles). La boucle principale sera alors : 

Variable Yapermute en Booleen 
Debut 

TantQue Yapermute 

Fi nTantQue 
Fin 

Que va-t-on faire a I’interieur de la boucle ? Prendre les elements du tableau, du premier jusqu’a I’avant- 
dernier, et proceder a un echange si necessaire. C’est parti : 


variable Yapermute en Booleen 
Debut 

TantQue Yapermute 
Pour i <- 0 a 10 

Si t(i) > t(i+l) Alors 
temp «- t(i) 
t(i ) <- t(i +1) 
t(i+l) <- temp 
Fi nsi 
i suivant 
Fin 

Mais il ne faut pas oublier un detail capital : la gestion de notre flag. L’idee, c’est que cette variable va nous 
signaler le fait qu’il y a eu au moins une permutation effectuee. II faut done : 

• lui attribuer la valeur Vrai des qu’une seule permutation a ete faite (il suffit qu’il y en ait eu une 
seule pour qu’on doive tout recommencer encore une fois). 

• la remettre a Faux a chaque tour de la boucle principale (quand on recommence un nouveau tour 
general de bulles, il n’y a pas encore eu d’elements echanges), 

• dernier point, il ne faut pas oublier de lancer la boucle principale, et pour cela de donner la valeur 
Vrai au flag au tout depart de I’algorithme. 

La solution complete donne done : 

Variable Yapermute en Booleen 
Debut 

Yapermut <- Vrai 
TantQue Yapermut 
Yapermut <- Faux 
Pour i <- 0 a 10 

si t(i) > t(i+l) alors 
temp «- t(i) 
t(i) <- t(i +1) 
t(i+l) «- temp 
Yapermut <- vrai 
Fi nsi 
i suivant 
FinTantQue 
Fin 

Au risque de me repeter, la comprehension et la maitrise du principe du flag font partie de I’arsenal du 
programmeur bien arme. 

4. La recherche dichotomique 

Je ne sais pas si on progresse vraiment en algorithmique, mais en tout cas, qu'est-ce qu'on apprend comme 
vocabulaire ! 

Blague dans le coin, nous allons terminer ce chapitre migraineux par une technique celebre de recherche, qui 
revele toute son utilite lorsque le nombre d'elements est tres eleve. Par exemple, imaginons que nous ayons un 
programme qui doive verifier si un mot existe dans le dictionnaire. Nous pouvons supposer que le dictionnaire a ete 
prealablement entre dans un tableau (a raison d'un mot par emplacement). Ceci peut nous mener a, disons a la 
louche, 40 000 mots. 

Une premiere maniere de verifier si un mot se trouve dans le dictionnaire consiste a examiner successivement 
tous les mots du dictionnaire, du premier au dernier, et a les comparer avec le mot a verifier. Ca marche, mais 
cela risque d'etre long : si le mot ne se trouve pas dans le dictionnaire, le programme ne le saura qu'apres 40 000 


tours de boucle ! Et meme si le mot figure dans le dictionnaire, la reponse exigera tout de meme en moyenne 20 
000 tours de boucle. C'est beaucoup, meme pour un ordinateur. 

Or, il y a une autre maniere de chercher, bien plus intelligente pourrait-on dire, et qui met a profit le fait que 
dans un dictionnaire, les mots sont tries par ordre alphabetique. D'ailleurs, un etre humain qui cherche un mot dans 
le dictionnaire ne lit jamais tous les mots, du premier au dernier : il utilise lui aussi le fait que les mots sont tries. 

Pour une machine, quelle est la maniere la plus rationnelle de chercher dans un dictionnaire ? C'est de comparer 
le mot a verifier avec le mot qui se trouve pile poil au milieu du dictionnaire. Si le mot a verifier est anterieur dans 
I'ordre alphabetique, on sait qu'on devra le chercher dorenavant dans le premiere moitie du dico. Sinon, on sait 
maintenant qu'on devra le chercher dans la deuxieme moitie. 

A partir de la, on prend la moitie de dictionnaire qui nous reste, et on recommence : on compare le mot a 
chercher avec celui qui se trouve au milieu du morceau de dictionnaire restant. On ecarte la mauvaise moitie, et 
on recommence, et ainsi de suite. 

A force de couper notre dictionnaire en deux, puis encore en deux, etc. on va finir par se retrouver avec des 
morceaux qui ne contiennent plus qu'un seul mot. Et si on n'est pas tombe sur le bon mot a un moment ou a un 
autre, c'est que le mot a verifier ne fait pas partie du dictionnaire. 

Regardons ce que cela donne en terme de nombre d'operations a effectuer, en choisissant le pire cas : celui ou 
le mot est absent du dictionnaire. 

• Au depart, on cherche le mot parmi 40 000. 

• Apres le test n” 1 , on ne le cherche plus que parmi 20 000. 

• Apres le test n°2, on ne le cherche plus que parmi 10 000. 

• Apres le test n°3, on ne le cherche plus que parmi 5 000. 

• etc. 

• Apres le test n°15, on ne le cherche plus que parmi 2. 

• Apres le test n°16, on ne le cherche plus que parmi 1. 

Et la, on sait que le mot n'existe pas. Moralite : on a obtenu notre reponse en 16 operations contre 40 000 
precedemment ! Il n'y a pas photo sur I'ecart de performances entre la technique barbare et la technique futee. 
Attention, toutefois, meme si c'est evident, je le repete avec force : la recherche dichotomique ne peut s'effectuer 
que sur des elements prealablement tries. 

Eh bien maintenant que je vous ai explique comment faire, vous n'avez plus qu'a traduire ! 

Au risque de me repeter, la comprehension et la maitrise du principe du flag font partie du bagage du 
programmeur bien outille. 



Parti e 8 

Tableaux Multidimensionnels 

Ceci n’est pas un dereglement de votre televiseur. Nous controlons tout, nous savons tout, et les phenomenes 
paranormaux que vous constatez sont dus au fait que vous etes passes dans... la quatrieme dimension (musique 
angoissante : « tintintin... »). 

Oui, enfin bon, avant d’attaquer la quatrieme, on va deja se coltiner la deuxieme. 

1. POURQUOI PLUSIEURS DIMENSIONS ? 

Une seule ne suffisait-elle pas deja amplement a notre bonheur, me demanderez-vous ? Certes, repondrai-je, 
mais vous allez voir qu’avec deux (et davantage encore) c’est carrement le nirvana. 

Prenons le cas de la modelisation d’un jeu de dames, et du deplacement des pions sur le damier. Je rappelle 
qu’un pion qui est sur une case blanche peut se deplacer (pour simplifier) sur les quatre cases blanches adjacentes. 

Avec les outils que nous avons abordes jusque la, le plus simple serait evidemment de modeliser le damier sous 
la forme d’un tableau. Chaque case est un emplacement du tableau, qui contient par exemple 0 si elle est vide, et 
1 s’il y a un pion. On attribue comme indices aux cases les numeros 1 a 8 pour la premiere ligne, 9 a 16 pour la 
deuxieme ligne, et ainsi de suite jusqu’a 64. 

Arrives a ce stade, les fines mouches du genre de Cyprien L. m'ecriront pour faire remarquer qu'un damier, cela 
possede 100 cases et non 64, et qu'entre les damiers et les echiquiers, je me suis joyeusement emmele les pedales. 
A ces fines mouches, je ferai une double reponse de prof : 

1 . C'etait pour voir si vous suiviez. 

2. Si le prof decide contre toute evidence que les damiers font 64 cases, c'est le prof qui a raison et 

I'evidence qui a tort. Rompez. 

Reprenons. Un pion place dans la case numero i, autrement dit la valeur 1 de Cases(i), peut bouger vers les 
cases contigues en diagonale. Cela va nous obliger a de petites acrobaties intellectuelles : la case situee juste au- 
dessus de la case numero i ayant comme indice i-8, les cases valables sont celles d’indice i-7 et i-9. De meme, la 
case situee juste en dessous ayant comme indice i+8, les cases valables sont celles d’indice i+7 et i+9. 

Bien sur, on peut fabriquer tout un programme comme cela, mais le moins qu’on puisse dire est que cela ne 
facilite pas la clarte de I’algorithme. 

II serait evidemment plus simple de modeliser un damier par... un damier ! 

2. Tableaux a deux dimensions 

L’informatique nous offre la possibility de declarer des tableaux dans lesquels les valeurs ne sont pas reperees 
par une seule, mais par deux coordonnees. 

Un tel tableau se declare ainsi : 

Tableau Cases (7, 7) en Numerique 

Cela veut dire : reserve moi un espace de memoire pour 8x8 entiers, et quand j’aurai besoin de I’une de ces 
valeurs, je les repererai par deux indices (comme a la bataille navale, ou Excel, la seule difference etant que pour 
les coordonnees, on n’utilise pas de lettres, juste des chiffres). 


Pour notre probleme de dames, les choses vont serieusement s’eclaircir. La case qui contient le pion est 
dorenavant Cases(i, j). Et les quatre cases disponibles sont Cases(i-1 , j-1 ), Cases(i-1 , j+1 ), Cases(i+1 , j-1 ) et 
Cases(i+1 , j+1 ). 




Une autre remarque : une question classique a propos des tableaux a deux dimensions est de savoir si le premier 
indice represente les lignes ou le deuxieme les colonnes, ou I’inverse. Je ne repondrai pas a cette question non 
parce que j’ai decide de bouder, mais parce qu’elle n’a aucun sens. « Lignes » et « Colonnes » sont des concepts 
graphiques, visuels, qui s’appliquent a des objets du monde reel ; les indices des tableaux ne sont que des 
coordonnees logiques, pointant sur des adresses de memoire vive. Si cela ne vous convainc pas, pensez a un jeu de 
bataille navale classique : les lettres doivent-elles designer les lignes et les chiffres les colonnes ? Aucune 
importance ! Chaque joueur peut meme choisir une convention differente, aucune importance ! L’essentiel est 
qu’une fois une convention choisie, un joueur conserve la meme tout au long de la partie, bien entendu. 

3. Tableaux a n dimensions 

Si vous avez compris le principe des tableaux a deux dimensions, sur le fond, il n’y a aucun probleme a passer au 
maniement de tableaux a trois, quatre, ou pourquoi pas neuf dimensions. C’est exactement la meme chose. Si je 
declare un tableau Titi (2, 4, 3, 3), il s’agit d’un espace memoire contenant 3x5x4x4 = 240 valeurs. Chaque 
valeur y est reperee par quatre coordonnees. 

Le principal obstacle au maniement systematique de ces tableaux a plus de trois dimensions est que le 
programmeur, quand il concoit son algorithme, aime bien faire des petits gribouillis, des dessins immondes, 
imaginer les boucles dans sa tete, etc. Or, autant il est facile d’imaginer concretement un tableau a une 
dimension, autant cela reste faisable pour deux dimensions, autant cela devient I’apanage d’une minorite 
privilegiee pour les tableaux a trois dimensions (je n’en fais malheureusement pas partie) et hors de portee de tout 
mortel au-dela. C’est comme ca, I’esprit humain a du mal a se representer les choses dans I’espace, et crie grace 
des qu’il saute dans I’hyperespace (oui, c’est comme ca que ca s’appelle au dela de trois dimensions). 

Done, pour des raisons uniquement pratiques, les tableaux a plus de trois dimensions sont rarement utilises par 
des programmeurs non matheux (car les matheux, de par leur formation, ont une facheuse propension a manier des 
espaces a n dimensions comme qui rigole, mais ce sont bien les seuls, et laissons les dans leur coin, c’est pas des 
gens comme nous). 



Parti e 9 

Les Fonctions Predefinies 

Certains traitements ne peuvent etre effectues par un algorithme, aussi savant soit-il. D’autres ne peuvent 
I’etre qu’au prix de souffrances indicibles. 

C’est par exemple le cas du calcul du sinus d’un angle : pour en obtenir une valeur approchee, il faudrait 
appliquer une formule d’une complexity a vous glacer le sang. Aussi, que se passe-t-il sur les petites calculatrices 
que vous connaissez tous ? On vous fournit quelques touches speciales, dites touches de fonctions, qui vous 
permettent par exemple de connaitre immediatement ce resultat. Sur votre calculatrice, si vous voulez connaitre 
le sinus de 35°, vous taperez 35, puis la touche SIN, et vous aurez le resultat. 

Tout langage de programmation propose ainsi un certain nombre de fonctions ; certaines sont indispensables, 
car elles permettent d’effectuer des traitements qui seraient sans elles impossibles. D’autres servent a soulager le 
programmeur, en lui epargnant de longs - et penibles - algorithmes. 

1 . Structure generale des fonctions 

Reprenons I’exemple du sinus. Les langages informatiques, qui se doivent tout de meme de savoir faire la meme 
chose qu’une calculatrice a 19F90, proposent generalement une fonction SIN. Si nous voulons Stocker le sinus de 35 
dans la variable A, nous ecrirons : 

A «- sin(35) 

Une fonction est done constitute de trois parties : 

• le nom proprement dit de la fonction. Ce nom ne s’invente pas ! II doit imperativement 
correspondre a une fonction proposee par le langage. Dans notre exemple, ce nom est SIN. 

• deux parentheses, une ouvrante, une fermante. Ces parentheses sont toujours obligatoires, meme 
lorsqu'on n'ecrit rien a I'interieur. 

• une liste de valeurs, indispensables a la bonne execution de la fonction. Ces valeurs s’appellent des 
arguments, ou des parametres. Certaines fonctions exigent un seul argument, d’autres deux, etc. et 
d’autres encore aucun. A noter que meme dans le cas de ces fonctions n’exigeant aucun argument, les 
parentheses restent obligatoires. Le nombre d’arguments necessaire pour une fonction donnee ne s’invente 
pas : il est fixe par le langage. Par exemple, la fonction sinus a besoin d’un argument (ce n’est pas 
surprenant, cet argument est la valeur de I’angle). Si vous essayez de I’executer en lui donnant deux 
arguments, ou aucun, cela declenchera une erreur a I’execution. Notez egalement que les arguments 
doivent etre d’un certain type, et qu’il faut respecter ces types. 

Et d'entree, nous trouvons : 

LE GAG DE LA JOURNEE 

Il consiste a affecter une fonction, quelle qu'elle soit. 

Toute ecriture placant une fonction a gauche d'une instruction d'affectation est aberrante, pour deux raisons 
symetriques. 


• d'une part, parce que nous le savons depuis le premier chapitre de ce cours extraordinaire, 
on ne peut affecter qu'une variable, a I'exclusion de tout autre chose. 

• ensuite, parce qu'une fonction a pour role de produire, de renvoyer, de valoir (tout cela est 
synonyme), un resultat. Pas d'en recevoir un, done. 

L'affectation d'une fonction sera done consideree comme I'une des pi res fautes algorithmiques, et punie comme 
telle. 

Tavernier... 


2. Les fonctions de texte 

Line categorie privilegiee de fonctions est celle qui nous permet de manipuler des chaTnes de caracteres. Nous 
avons deja vu qu’on pouvait facilement « coller » deux chaines I’une a I’autre avec I’operateur de concatenation 
St. Mais ce que nous ne pouvions pas faire, et qui va etre maintenant possible, c’est pratiquer des extractions de 
chaines (moins douloureuses, il faut le noter, que les extractions dentaires). 

Tous les langages, je dis bien tous, proposent peu ou prou les fonctions suivantes, meme si le nom et la syntaxe 
peuvent varier d’un langage a I’autre : 

• Len(chaTne) : renvoie le nombre de caracteres d’une chaine 

• Mid(chaTne,n1,n2) : renvoie un extrait de la chaine, commencant au caractere nl et faisant n2 

caracteres de long. 

Ce sont les deux seules fonctions de chaines reellement indispensables. Cependant, pour nous epargner des 
algorithmes fastidieux, les langages proposent egalement : 

• Left(chaTne,n) : renvoie les n caracteres les plus a gauche dans chaine. 

• Right(chaTne,n) : renvoie les n caracteres les plus a droite dans chaine 

• Trouve(chaTne1,chaTne2) : renvoie un nombre correspondant a la position de chaine2 dans 

chaTnel . Si chaine2 n’est pas comprise dans chaTnel , la fonction renvoie zero. 

Exemples : 


Len( Bonjour, ga va 

? ) 

vaut 

16 

Len("") 


vaut 

0 

Mfd("Zorro is back", 

4, 7) 

vaut 

"ro is b" 

Mid("zorro is back", 

12, 1) 

vaut 

"c" 

Left("Et pourtant..." , 

8) 

vaut 

"Et pourt 

Right("Et pourtant..." 

, 4) 

vaut 

ii ii 

Trouve("Un pur bonheur", "pur") 

vaut 

4 

Trouve("Un pur bonheur", "techno") 

vaut 

0 


II existe aussi dans tous les langages une fonction qui renvoie le caractere correspondant a un code Ascii donne 
(fonction Asc), et Lycee de Versailles (fonction Chr) : 

AscC'N") vaut 78 

Chr(63) vaut "?" 

J’insiste ; a moins de programmer avec un langage un peu particulier, comme le C, qui traite en realite les 
chaines de caracteres comme des tableaux, on ne pourrait pas se passer des deux fonctions Len et Mid pour traiter 
les chaTnes. Or, si les programmes informatiques ont frequemment a traiter des nombres, ils doivent tout aussi 
frequemment gerer des series de caracteres (des chaTnes). Je sais bien que cela devient un refrain, mais connattre 
les techniques de base sur les chaTnes est plus qu’utile : c’est indispensable. 

3. Trois fonctions numeriques classiques 

Partie Entiere 

Une fonction extremement repandue est celle qui permet de recuperer la partie entiere d’un nombre : 

Apres : A <- Ent(3,228) A vaut 3 

Cette fonction est notamment indispensable pour effectuer le celebrissime test de parite (voir exercice dans pas 
longtemps). 

Modulo 

Cette fonction permet de recuperer le reste de la division d’un nombre par un deuxieme nombre. Par exemple : 


A <- Mod (10, B) A vaut 1 car 10 = 3*3 + 1 

B <- Mod (12, 2) B vaut 0 car 12 = 6*2 

C «- Mod (44, 8) C vaut 4 car 44 = 5*8 + 4 

Cette fonction peut paraitre un peu bizarre, est reservee aux seuls matheux. Mais vous aurez la aussi I’occasion 

de voir dans les exercices a venir que ce n’est pas le cas. 

Generation de nombres aleatoires 

Line autre fonction classique , car tres utile, est celle qui genere un nombre choisi au hasard. 

Tous les programmes de jeu, ou presque, ont besoin de ce type d’outils, qu’il s’agisse de simuler un lancer de 
des ou le deplacement chaotique du vaisseau spatial de I’enfer de la mort pilote par I’infame Zorglub, qui veut 
faire main basse sur I’Univers (heureusement vous etes la pour I’en empecher, ouf). 

Mais il n’y a pas que les jeux qui ont besoin de generer des nombres aleatoires. La modelisation (physique, 
geographique, economique, etc.) a parfois recours a des modeles dits stochastiques (chouette, encore un nouveau 
mot savant !). Ce sont des modeles dans lesquels les variables se deduisent les unes des autres par des relations 
deterministes (autrement dit des calculs), mais ou I’on simule la part d’incertitude par une « fourchette » de 
hasard. 

Par exemple, un modele demographique supposera qu’une femme a en moyenne x enfants au cours de sa vie, 
mettons 1,5. Mais il supposera aussi que sur une population donnee, ce chiffre peut fluctuer entre 1 ,35 et 1 ,65 (si 
on laisse une part d’incertitude de 10%). Chaque annee, c’est-a-dire chaque serie de calcul des valeurs du modele, 
on aura ainsi besoin de faire choisir a la machine un nombre au hasard compris entre 1,35 et 1,65. 

Dans tous les langages, cette fonction existe et produit le resultat suivant : 

Apres : Toto <- Alea() On a : 0 =< Toto < 1 

En fait, on se rend compte avec un tout petit peu de pratique que cette fonction Alea peut nous servir pour 
generer n’importe quel nombre compris dans n’importe quelle fourchette. Je sais bien que mes lecteurs ne sont 
guere matheux, mais la, on reste franchement en deca du niveau de feu le BEPC : 

• si Alea genere un nombre compris entre 0 et 1, Alea multiplie par Z produit un nombre entre 0 et Z. 

Done, il faut estimer la « largeur » de la fourchette voulue et multiplier Alea par cette « largeur » desiree. 

• ensuite, si la fourchette ne commence pas a zero, il va suffire d’ajouter ou de retrancher quelque 

chose pour « caler » la fourchette au bon endroit. 

Par exemple, si je veux generer un nombre entre 1 ,35 et 1 ,65 ; la « fourchette » mesure 0,30 de large. Done : 0 
=< Alea()*0,30 < 0,30 

Il suffit des lors d’ajouter 1,35 pour obtenir la fourchette voulue. Si j’ecris que : 

Toto <- Alea()*0,30 + 1,35 

Toto aura bien une valeur comprise entre 1,35 et 1 ,65. Et le tour est joue ! 

Bon, il est grand temps que vous montriez ce que vous avez appris... 

4. Les fonctions de conversion 

Derniere grande categorie de fonctions, la aussi disponibles dans tous les langages, car leur role est parfois 
incontournable, les fonctions dites de conversion. 

Rappelez-vous ce que nous avons vu dans les premieres pages de ce cours : il existe differents types de 
variables, qui determinent notamment le type de codage qui sera utilise. Prenons le chiffre 3. Si je le stocke dans 
une variable de type alphanumerique, il sera code en tant que caractere, sur un octet. Si en revanche je le stocke 
dans une variable de type entier, il sera code sur deux octets. Et la configuration des bits sera completement 
differente dans les deux cas. 

Une conclusion evidente, et sur laquelle on a deja eu (occasion d'insister, e'est qu'on ne peut pas faire n'importe 
quoi avec n'importe quoi, et qu'on ne peut pas par exemple multiplier "3" et "5", si 3 et 5 sont stockes dans des 


variables de type caractere. Jusque la, pas de scoop me direz-vous, a juste titre vous repondrai-je, mais attendez 
done la suite. 

Pourquoi ne pas en tirer les consequences, et stocker convenablement les nombres dans des variables 
numeriques, les caracteres dans des variables alphanumeriques, comme nous I'avons toujours fait ? 

Parce qu'il y a des situations ou on n'a pas le choix ! Nous allons voir des le chapitre suivant un mode de stockage 
(les fichiers textes) ou toutes les informations, quelles qu'elles soient, sont obligatoirement stockees sous forme de 
caracteres. Des lors, si I'on veut pouvoir recuperer des nombres et faire des operations dessus, il va bien falloir 
etre capable de convertir ces chaines en numeriques. 

Aussi, tous les langages proposent-ils une palette de fonctions destinees a operer de telles conversions. On 
trouvera au moins une fonction destinee a convertir une chaine en numerique (appelons-la Cnum en pseudo-code), 
et une convertissant un nombre en caractere (Ccar). 



Parti e 10 
Les Fichiers 

Jusqu’a present, les informations utilisees dans nos programmes ne pouvaient provenir que de deux sources : 
soit elles etaient inclues dans I’algorithme lui-meme, par le programmeur, soit elles etaient entrees en cours de 
route par I’utilisateur. Mais evidemment, cela ne suffit pas a combler les besoins reels des informaticiens. 

Imaginons que I’on veuille ecrire un programme gerant un carnet d’adresses. D’une execution du programme a 
I’autre, I’utilisateur doit pouvoir retrouver son carnet a jour, avec les modifications qu’il y a apportees la derniere 
fois qu’il a execute le programme. Les donnees du carnet d’adresse ne peuvent done etre inclues dans 
I’algorithme, et encore moins etre entrees au clavier a chaque nouvelle execution ! 

Les fichiers sont la pour combler ce manque. Ils servent a stocker des informations de maniere permanente, 
entre deux executions d’un programme. Car si les variables, qui sont je le rappelle des adresses de memoire vive, 
disparaissent a chaque fin d ’execution, les fichiers, eux sont stockes sur des peripheriques a memoire de masse 
(disquette, disque dur, CD Rom...). 

1 . Organisation des fichiers 

Vous connaissez tous le coup des papous : « chez les papous, il y a les papous papas et les papous pas papas. 
Chez les papous papas, il y a les papous papas a poux et les papous papas pas a poux, etc. » Eh bien les fichiers, 
e'est un peu pareil : il y a des categories, et dans les categories, des sortes, et dans les sortes des especes. Essayons 
done de debroussailler un peu tout cela... 

Un premier grand critere, qui differencie les deux grandes categories de fichiers, est le suivant : le fichier est-il 
ou non organise sous forme de lignes successives ? Si oui, cela signifie vraisemblablement que ce fichier contient 
le meme genre d'information a chaque ligne. Ces lignes sont alors appelees des enregistrements. 

Afin d'illuminer ces propos obscurs, prenons le cas classique, celui d'un carnet d'adresses. Le fichier est destine a 
memoriser les coordonnees (ce sont toujours les plus mal chaussees, bien sur) d'un certain nombre de personnes. 
Pour chacune, il faudra noter le nom, le prenom, le numero de telephone et I'email. Dans ce cas, il peut paraitre 
plus simple de stocker une personne par ligne du fichier (par enregistrement). Dit autrement, quand on prendra 
une ligne, on sera sur qu'elle contient les informations concernant une personne, et uniquement cela. Un fichier 
ainsi code sous forme d'enregistrements est appele un fichier texte. 

En fait, entre chaque enregistrement, sont stockes les octets correspondants aux caracteres CR (code Ascii 13) 
et LF (code Ascii 10), signifiant un retour au debut de la ligne suivante. Le plus souvent, le langage de 
programmation, des lors qu'il s'agit d'un fichier texte, gerera lui-meme la lecture et I'ecriture de ces deux 
caracteres a chaque fin de ligne : e'est autant de moins dont le programmeur aura a s'occuper. Le programmeur, 
lui, n'aura qu'a dire a la machine de lire une ligne, ou d'en ecrire une. 

Ce type de fichier est couramment utilise des lors que I'on doit stocker des informations pouvant etre assimilees 
a une base de donnees. 

Le second type de fichier, vous I'aurez devine, se definit a contrario : il rassemble les fichiers qui ne possedent 
pas de structure de lignes (d'enregistrement). Les octets, quels qu'il soient, sont ecrits a la queue leu leu. Ces 
fichiers sont appeles des fichiers binaires. Naturellement, leur structure differente implique un traitement 
different par le programmeur. Tous les fichiers qui ne codent pas une base de donnees sont obligatoirement des 
fichiers binaires : cela concerne par exemple un fichier son, une image, un programme executable, etc. . 

Toutefois, on en dira quelques mots un peu plus loin, il est toujours possible d'opter pour une structure binaire 
meme dans le cas ou le fichier represente une base de donnees. 

Autre difference majeure entre fichiers texte et fichiers binaires : dans un fichier texte, toutes les donnees sont 
ecrites sous forme de... texte (etonnant, non ?). Cela veut dire que les nombres y sont represents sous forme de 
suite de chiffres (des chaines de caracteres). Ces nombres doivent done etre convertis en chaTnes lors de 
I'ecriture dans le fichier. Inversement, lors de la lecture du fichier, on devra convertir ces chaTnes en nombre si 



I'on veut pouvoir les utiliser dans des calculs. En revanche, dans les fichiers binaires, les donnees sont ecrites a 
I'image exact de leur codage en memoire vive, ce qui epargne toutes ces operations de conversion. 

Ceci a comme autre implication qu'un fichier texte est directement lisible, alors qu'un fichier binaire ne I'est 
pas(sauf bien sir en ecrivant soi-meme un programme approprie). Si I'on ouvre un fichier texte via un editeur de 
textes, comme le bloc-notes de Windows, on y reconnaitra toutes les informations (ce sont des caracteres, stockes 
comme tels). La meme chose avec un fichier binaire ne nous produit a I'ecran qu'un galimatias de scribouillis 
incomprehensibles. 

2. Structure des enregistrements 

Savoir que les fichiers peuvent etre structures en enregistrements, c'est bien. Mais savoir comment sont a leur 
tour structures ces enregistrements, c'est mieux. Or, la aussi, il y a deux grandes possibilites. Ces deux grandes 
variantes pour structurer les donnees au sein d’un fichier texte sont la delimitation et les champs de largeur fixe. 

Reprenons le cas du carnet d’adresses, avec dedans le nom, le prenom, le telephone et I'email. Les donnees, sur 
le fichier texte, peuvent etre organisees ainsi : 

Structure n°l 

"Fonfec" ; "Sophie" ;0142156487 ; "fonfec@yahoo.fr" 

"zetof rai s" ; "Melani e" ; 0456912347 ; "zetof rai s@f ree . f r" 

"Herbi en" ; "lean -Phi 1 i ppe" ; 0289765194 ; "vantard@f ree . f r" 

"Hergebel " ; "Octave" ; 0149875231; "rg@aol . f r" 

ou ainsi : 
structure n°2 

Fonfec Sophie 0142156487fonfec@yahoo.fr 

zetof rai s Melanie 0456912347zetofrais@free.fr 

Herbien Jean-Phi 1 i ppe 0289765194vantard@free.fr 

Hergebel Octave 0149875231rg@aol.fr 

La structure n°1 est dite delimitee ; Elle utilise un caractere special, appele caractere de delimitation, qui 
permet de reperer quand finit un champ et quand commence le suivant. II va de soi que ce caractere de 
delimitation doit etre strictement interdit a I’interieur de chaque champ, faute de quoi la structure devient 
proprement illisible. 

La structure n°2, elle, est dite a champs de largeur fixe. II n’y a pas de caractere de delimitation, mais on sait 
que les x premiers caracteres de chaque ligne stockent le nom, les y suivants le prenom, etc. Cela impose bien 
entendu de ne pas saisir un renseignement plus long que le champ prevu pour I’accueillir. 

• L’avantage de la structure n°1 est son faible encombrement en place memoire ; il n’y a aucun 
espace perdu, et un fichier texte code de cette maniere occupe le minimum de place possible. Mais elle 
possede en revanche un inconvenient majeur, qui est la lenteur de la lecture. En effet, chaque fois que 
I’on recupere une ligne dans le fichier, il faut alors parcourir un par un tous les caracteres pour reperer 
chaque occurrence du caractere de separation avant de pouvoir decouper cette ligne en differents champs. 

• La structure n°2, a I’inverse, gaspille de la place memoire, puisque le fichier est un vrai gruyere 
plein de trous. Mais d’un autre cote, la recuperation des differents champs est tres rapide. Lorsqu’on 
recupere une ligne, il suffit de la decouper en differentes chaines de longueur predefinie, et le tour est 
joue. 

A I’epoque ou la place memoire coutait cher, la structure delimitee etait souvent privilegiee. Mais depuis bien 
des annees, la quasi -totalite des logiciels - et des programmeurs - optent pour la structure en champs de largeur 
fixe. Aussi, sauf mention contraire, nous ne travaillerons qu’avec des fichiers batis sur cette structure. 

Remarque importante : lorsqu'on choisit de coder une base de donnees sous forme de champs de largeur fixe, on 
peut alors tres bien opter pour un fichier binaire. Les enregistrements y seront certes a la queue leu leu, sans que 
rien ne nous signale la jointure entre chaque enregistrement. Mais si on sait combien d'octets mesure 
invariablement chaque champ, on sait du coup combien d'octets mesure chaque enregistrement. Et on peut done 
tres facilement recuperer les informations : si je sais que dans mon carnet d'adresse, chaque individu occupe 


mettons 75 octets, alors dans mon fichier binaire, je deduis que I'individu n°1 occupe les octets 1 a 75, I'individu 
n°2 les octets 76 a 150, I'individu n°3 les octets 151 a 225, etc. 

3. Types d’acces 

On vient de voir que I’organisation des donnees au sein des enregistrements du fichier pouvait s’effecteur selon 
deux grands choix strategiques. Mais il existe une autre ligne de partage des fichiers : le type d’acces, autrement 
dit la maniere dont la machine va pouvoir aller rechercher les informations contenues dans le fichier. 

On distingue : 

• L’acces sequentiel : on ne peut acceder qu’a la donnee suivant celle qu’on vient de lire. On ne 
peut done acceder a une information qu'en ayant au prealable examine celle qui la precede. Dans le cas 
d'un fichier texte, cela signifie qu'on lit le fichier ligne par ligne (enregistrement par enregistrement). 

• L’acces direct (ou aleatoire) : on peut acceder directement a I’enregistrement de son choix, en 
precisant le numero de cet enregistrement. Mais cela veut souvent dire une gestion fastidieuse des 
deplacements dans le fichier. 

• L’acces indexe : pour simplifier, il combine la rapidite de I'acces direct et la simplicity de I'acces 
sequentiel (en restant toutefois plus complique). Il est particulierement adapte au traitement des gros 
fichiers, comme les bases de donnees importantes. 

A la difference de la precedente, cette typologie ne caracterise pas la structure elle-meme du fichier. En fait, 
tout fichier peut etre utilise avec I’un ou I’autre des trois types d’acces. Le choix du type d’acces n’est pas un 
choix qui concerne le fichier lui-meme, mais uniquement la maniere dont il va etre traite par la machine. C’est 
done dans le programme, et seulement dans le programme, que I’on choisit le type d’acces souhaite. 

Pour conclure sur tout cela, void un petit tableau recapitulate : 



Fichiers Texte 

Fichiers Binaires 

On les utilise pour Stocker... 

des bases de donnees 

tout, y compris des bases de donnees. 

Ils sont structures sous forme de... 

lignes (enregistrements) 

Ils n'ont pas de structure apparente. Ce sont 
des octets ecrits a la suite les uns des autres. 

Les donnees y sont ecrites... 

exclusivement en tant que caracteres 

comme en memoire vive 

Les enregistrements sont eux- 
memes structures... 

au choix, avec un separateur ou en 
champs de largeur fixe 

en champs de largeur fixe, s'il s'agit d'un 
fichier codant des enregistrements 

Lisibilite 

Le fichier est lisible clairement avec 
n'importe quel editeur de texte 

Le fichier a I'apparence dune suite d'oetets 
illisibles 

Lecture du fichier 

On ne peut lire le fichier que ligne par 
ligne 

On peut lire les octets de son choix (y compris 
la totalite du fichier d'un coup) 


Dans le cadre de ce cours, on se limitera volontairement au type de base : le fichier texte en acces sequentiel. 
Pour des informations plus completes sur la gestion des fichiers binaires et des autres types d'acces, il vous 
faudra... chercher ailleurs. 


4. Instructions (fichiers texte en acces sequentiel) 

Si I’on veut travailler sur un fichier, la premiere chose a faire est de I’ouvrir. Cela se fait en attribuant au 
fichier un numero de canal. On ne peut ouvrir qu’un seul fichier par canal, mais quel que soit le langage, on 
dispose toujours de plusieurs canaux, done pas de soucis. 

L’important est que lorsqu’on ouvre un fichier, on stipule ce qu’on va en faire : lire, ecrire ou ajouter. 

• Si on ouvre un fichier pour lecture, on pourra uniquement recuperer les informations qu’il 
contient, sans les modifier en aucune maniere. 


• Si on ouvre un fichier pour ecriture, on pourra mettre dedans toutes les informations que I’on veut. 
Mais les informations precedentes, si elles existent, seront integralement ecrasees Et on ne pourra pas 
acceder aux informations qui existaient precedemment. 

• Si on ouvre un fichier pour ajout, on ne peut ni lire, ni modifier les informations existantes. Mais on 
pourra, comme vous commencez a vous en douter, ajouter de nouvelles lignes (je rappelle qu'au terme de 
lignes, on preferera celui d’enregistrements. 

Au premier abord, ces limitations peuvent sembler infernales. Au deuxieme rabord, elles le sont effectivement. 

II n'y a meme pas destructions qui permettent de supprimer un enregistrement d'un fichier ! 

Toutefois, avec un peu d’habitude, on se rend compte que malgre tout, meme si ce n’est pas toujours marrant, 
on peut quand meme faire tout ce qu’on veut avec ces fichiers sequentiels. 

Pour ouvrir un fichier texte, on ecrira par exemple : 

Ouvrir "Exemple.txt" sur 4 en Lecture 

lei, "Exemple.txt" est le nom du fichier sur le disque dur, 4 est le numero de canal, et ce fichier a done ete 
ouvert en lecture. Vous I’aviez sans doute pressenti. Allons plus loin : 

Variables True, Nom, Prenom, Tel, Mail en Caracteres 
Debut 

Ouvrir "Exemple.txt" sur 4 en Lecture 
LireFichier 4, True 
Nom <- Mid(Truc, 1, 20) 

Prenom «- Mid(Truc, 21, 15) 

Tel <- Mid(Truc, 36, 10) 

Mail <- MidfTruc, 46, 20) 

L’instruction LireFichier recupere done dans la variable specifiee I’enregistrement suivant dans le fichier... 
"suivant", oui, mais par rapport a quoi ? Par rapport au dernier enregistrement lu. C’est en cela que le fichier est 
dit sequentiel. En I’occurrence, on recupere done la premiere ligne, done, le premier enregistrement du fichier, 
dans la variable True. Ensuite, le fichier etant organise sous forme de champs de largeur fixe, il suffit de 
tronconner cette variable True en autant de morceaux qu’il y a de champs dans I’enregistrement, et d’envoyer ces 
troncons dans differentes variables. Et le tour est joue. 

La suite du raisonnement s’impose avec une logique impitoyable : lire un fichier sequentiel de bout en bout 
suppose de programmer une boucle. Comme on sait rarement a I’avance combien d’enregistrements comporte le 
fichier, la combine consiste neuf fois sur dix a utiliser la fonction EOF (acronyme pour End Of File). Cette fonction 
renvoie la valeur Vrai si on a atteint la fin du fichier (auquel cas une lecture supplemental declencherait une 
erreur). L’algorithme, ultra classique, en pareil cas est done : 
variable True en caractere 
Ouvrir "Exemple.txt" sur 5 en Lecture 
Debut 

Tantque Non EOF(5) 

LireFichier 5, True 

Fi nTantQue 
Fermer 5 
Fin 

Et neuf fois sur dix egalement, si I’on veut Stocker au fur et a mesure en memoire vive les informations lues 
dans le fichier, on a recours a un ou plusieurs tableaux. Et comme on ne sait pas d’avance combien il y aurait 
d’enregistrements dans le fichier, on ne sait pas davantage combien il doit y avoir d’emplacements dans les 
tableaux. Qu’importe, les programmeurs avertis que vous etes connaissent la combine des tableaux dynamiques. 

En rassemblant I’ensemble des connaissances acquises, nous pouvons done ecrire le prototype du code qui 
effectue la lecture integrate d’un fichier sequentiel, tout en recopiant I’ensemble des informations en memoire 
vive : 

Tableaux Nom(), PrenomO, Tel(), Mail () en Caractere 
Debut 


Ouvrir "Exemple.txt" sur 5 en Lecture 

i <- -1 

Tantque Non eof(5) 

LireFichier 5, True 
i <- i + 1 
Redim Nom(i) 

Redim Prenom(i) 

Redim Tel (i ) 

Redim Mail(i) 

Nom(i) <- Mid(Truc, 1, 20) 

Prenom(i) <- Mid(Truc, 21, 15) 

Tel(i) <- Mid(Truc, 36, 10) 

Mail(i) <- Mid (True, 46, 20) 

FinTantQue 
Fermer 5 
Fin 

lei, on a fait le choix de recopier le fichier dans quatre tableaux distincts. On aurait pu egalement tout recopier 
dans un seul tableau : chaque case du tableau aurait alors ete occupee par une ligne complete (un enregistrement) 
du fichier. Cette solution nous aurait fait gagner du temps au depart, mais elle alourdit ensuite le code, puisque 
chaque fois que I'on a besoin d'une information au sein d'une case du tableau, il faudra aller proceder a une 
extraction via la fonction MID. Ce qu'on gagne par un bout, on le perd done par I'autre. 

Mais surtout, comme on va le voir bientot, il y a autre possibilite, bien meilleure, qui cumule les avantages sans 
avoir aucun des inconvenients. 

Neanmoins, ne nous impatientons pas, chaque chose en son temps, et revenons pour le moment a la solution 
que nous avons employee ci-dessus. 

Pour une operation d’ecriture, ou d’ajout, il faut d’abord imperativement, sous peine de semer la panique dans 
la structure du fichier, constituer une chaine equivalente a la nouvelle ligne du fichier. Cette chaine doit done etre 
« calibree » de la bonne maniere, avec les differents champs qui « tombent » aux emplacements corrects. Le 
moyen le plus simple pour s’epargner de longs traitements est de proceder avec des chaines correctement 
dimensionnees des leur declaration (la plupart des langages offrent cette possibilite) : 

Ouvrir "Exemple.txt" sur 3 en Ajout 
Variable True en Caractere 

variables Nom*20, Prenom*15, Tel*10, Mail*20 en Caractere 

Une telle declaration assure que quel que soit le contenu de la variable Norn, par exemple, celle-ci comptera 
toujours 20 caracteres. Si son contenu est plus petit, alors un nombre correct d’espaces sera automatiquement 
ajoute pour combler. Si on tente d’y entrer un contenu trap long, celui-ci sera automatiquement tronque. Voyons 
la suite : 

Nom <- "Jokers" 

Prenom <- "Midnight" 

Tel - "0348946532" 

Mail <- "allstars@rockandroll.com" 

True <- Nom & Prenom & Tel & Mail 
Ecri reFichier 3, True 

Et pour finir, une fois qu’on en a termine avec un fichier, il ne faut pas oublier de fermer ce fichier. On libere 
ainsi le canal qu’il occupait (et accessoirement, on pourra utiliser ce canal dans la suite du programme pour un 
autre fichier... ou pour le meme). 

5. Strategies detraitement 

Il existe globalement deux manieres de traiter les fichiers textes : 

• I’une consiste a s’en tenir au fichier proprement dit, e'est-a-dire a modifier directement (ou 
presque) les informations sur le disque dur. C’est parfois un peu acrobatique, lorsqu’on veut supprimer un 
element d’un fichier : on programme alors une boucle avec un test, qui recopie dans un deuxieme fichier 


tous les elements du premier fichier sauf un ; et il faut ensuite recopier integralement le deuxieme fichier 
a la place du premier fichier... Ouf. 

• I’autre strategie consiste, comme on I’a vu, a passer par un ou plusieurs tableaux. En fait, le 
principe fondamental de cette approche est de commencer, avant toute autre chose, par recopier 
I’integralite du fichier de depart en memoire vive. Ensuite, on ne manipule que cette memoire vive 
(concretement, un ou plusieurs tableaux). Et lorsque le traitement est termine, on recopie a nouveau dans 
I'autre sens, depuis la memoire vive vers le fichier d’origine. 

Les avantages de la seconde technique sont nombreux, et 99 fois sur 100, c'est ainsi qu'il faudra proceder : 

• la rapidite : les acces en memoire vive sont des milliers de fois plus rapides (nanosecondes) que les 
acces aux memoires de masse (millisecondes au mieux pour un disque dur). En basculant le fichier du 
depart dans un tableau, on minimise le nombre ulterieur d'acces disque, tous les traitements etant ensuite 
effectues en memoire. 

• la facilite de programmation : bien qu’il faille ecrire les instructions de recopie du fichier dans le 
tableau, pour peu qu’on doive tripoter les informations dans tous les sens, c’est largement plus facile de 
faire cela avec un tableau qu’avec des fichiers. 

Pourquoi, alors, demanderez-vous haletants, ne fait-on pas cela a tous les coups ? Y a-t-il des cas ou il vaut 
mieux en rester aux fichiers et ne pas passer par des tableaux ? 

La recopie d’un tres gros fichier en memoire vive exige des ressources qui peuvent atteindre des dimensions 
considerables. Done, dans le cas d'immenses fichiers (tres rares, cependant), cette recopie en memoire peut 
s'averer problematique. 

Toutefois, lorsque le fichier contient des donnees de type non homogenes (chaTnes, numeriques, etc.) cela 
risque d’etre coton pour le stocker dans un tableau unique : il va falloir declarer plusieurs tableaux, dont le 
maniement au final peut etre aussi lourd que celui des fichiers de depart. 

A moins... d'utiliser une ruse : creer des types de variables personnalises, composes d’un « collage » de plusieurs 
types existants (10 caracteres, puis un numerique, puis 15 caracteres, etc.). Ce type de variable s'appelle un type 
structure. Cette technique, bien qu’elle ne soit pas vraiment difficile, exige tout de meme une certaine aisance... 
Voila pourquoi on va maintenant en dire quelques mots. 

6. Donnees structurees 

6.1 Donnees structurees simples 

Nostalgiques du Lego, cette partie va vous plaire. Comment construire des trues pas possibles et des machins 
pas croyables avec juste quelques elements de base ? Vous n'allez pas tarder a le savoir... 

Jusqu'a present, voila comment se presentaient nos possibilites en matiere de memoire vive : nous pouvions 
reserver un emplacement pour une information d'un certain type. Un tel emplacement s'appelle une variable 
(quand vous en avez assez de me voir radoter, vous le dites). Nous pouvions aussi reserver une serie d'emplacement 
numerates pour une serie d'informations de meme type. Un tel emplacement s'appelle un tableau (meme 
remarque). 

Eh bien toujours plus haut, toujours plus fort, void maintenant que nous pouvons reserver une serie 
d'emplacements pour des donnees de type differents. Un tel emplacement s'appelle une variable structuree. 

Son utilite, lorsqu'on traite des fichiers texte (et meme, des fichiers en general), saute aux yeux : car on va pouvoir 
calquer chacune des lignes du fichier en memoire vive, et considerer que chaque enregistrement sera recopie dans 
une variable et une seule, qui lui sera adaptee. Ainsi, le probleme du "decoupage" de chaque enregistrement en 
differentes variables (le nom, le prenom, le numero de telephone, etc.) sera resolu d'avance, puisqu'on aura une 
structure, un gabarit, en quelque sorte, tout pret d'avance pour accueilliret predecouper nos enregistrements. 



Attention toutefois ; lorsque nous utilisions des variables de type predefini, comme des entiers, des booleens, 
etc. nous n'avions qu'une seule operation a effectuer : declarer la variable en utilisant un des types existants. A 
present que nous voulons creer un nouveau type de variable (par assemblage de types existants), il va falloir faire 
deux choses : d'abord, creer le type. Ensuite seulement, declarer la (les) variable(s) d'apres ce type. 

Reprenons une fois de plus I'exemple du carnet d'adresses. Je sais, c'est un peu comme mes blagues, ca lasse 
(la, pour ceux qui s'endorment, je signale qu'il y a un jeu de mots), mais c'est encore le meilleur moyen d'avoir un 
point de comparaison. 

Nous allons done, avant meme la declaration des variables, creer un type, une structure, calquee sur celle de 
nos enregistrements, et done prete a les accueillir : 

Structure Bottin 

Nom en Caractere * 20 

Prenom en Caractere * 15 

Tel en Caractere * 10 

Mail en Caractere * 20 
Fin Structure 

lei, Bottin est le nom de ma structure. Ce mot jouera par la suite dans mon programme exactement le meme 
role que les types predefinis comme Numerique, Caractere ou Booleen. Maintenant que la structure est definie, je 
vais pouvoir, dans la section du programme ou s'effectuent les declarations, creer une ou des variables 
correspondant a cette structure : 

Variable Individu en Bottin 

Et si cela me chantait, je pourrais remplir les differentes informations contenues au sein de la variable Individu 
de la maniere suivante : 

Individu <- "Joker", "Midnight", "0B48946552", "allstars@rock.com" 

On peut aussi avoir besoin d'acceder a un seul des champs de la variable structuree. Dans ce cas, on emploie le 
point : 

Individu. Nom <- "Joker" 

Individu . Prenom <- "Midnight" 

Individu. Tel - "0348946532" 

Individu. Mail <- "allstars@rockandroll.com" 

Ainsi, ecrire correctement une information dans le fichier est un jeu d'enfant, puisqu'on dispose d'une variable 
Individu au bon gabarit. Une fois remplis les differents champs de cette variable - ce qu'on vient de faire -, il n'y a 
plus qu'a envoyer celle-ci directement dans le fichier. Et zou ! 

Ecri reFi chier 3, Individu 

De la meme maniere, dans I'autre sens, lorsque j'effectue une operation de lecture dans le fichier Adresses, ma 
vie en sera considerablement simplifiee : la structure etant faite pour cela, je peux dorenavant me contenter de 
recopier une ligne du fichier dans une variable de type Bottin, et le tour sera joue. Pour charger I'individu suivant 
du fichier en memoire vive, il me suffira done d'ecrire : 

Li reFi chier 5, Individu 

Et la, direct, j'ai bien mes quatre renseignements accessibles dans les quatre champs de la variable individu. 
Tout cela, evidemment, parce que la structure de ma variable Individu correspond parfaitement a la structure des 
enregistrements de mon fichier. Dans le cas contraire, pour reprendre une expression connue, on ne decoupera pas 
selon les pointilles, et alors, je pense que vous imaginez le carnage... 

6.2 Tableaux de donnees structures 

Et encore plus loin, encore plus vite et encore plus fort. Si a partir des types simples, on peut creer des 
variables et des tableaux de variables, vous me voyez venir, a partir des types structures, on peut creer des 
variables structures.. . et des tableaux de variables structures. 

La, bien que pas si difficile que cela, ca commence a devenir vraiment baleze. Parce que cela veut dire que 
nous disposons d'une maniere de gerer la memoire vive qui va correspondre exactement a la structure d'un fichier 
texte (d'une base de donnees). Comme les structures se correspondent parfaitement, le nombre de manipulations a 


effectuer, autrement dit de lignes de programme a ecrire, va etre reduit au minimum. En fait, dans notre tableau 
structure, les champs des emplacements du tableau correspondront aux champs du fichier texte, et les indices des 
emplacements du tableaux correspondront aux differentes lignes du fichier. 

Void, a titre d'illustration, I'algorithme complet de lecture du fichier Adresses et de sa recopie integrate en 
memoire vive, en employant un tableau structure. 

Structure Botfin 
Nom en caractere * 20 
Prenom en Caractere * 15 
Tel en Caractere * 10 
Mail en Caractere * 20 
Fin structure 

Tableau MespotesO en Bottin 
Debut 

Ouvri r "Exemple.txt" sur 3 en Lecture 
i «- -1 

Tantque Non eof( 3) 
i <- i + 1 
Redim Mespotes(i) 

LireFichier 3, Mespotes(i) 

Fi nTantQue 
Fermer 3 
Fin 

Une fois que ceci est regie, on a tout ce qu'il faut ! Si je voulais ecrire, a un moment, le mail de I'individu n°13 
du fichier (done le n°12 du tableau) a I'ecran, il me suffirait de passer I'ordre : 

Ecrire Mespotes(12) .Mail 

Et voila le travail. Simplissime, non ? 

REAAARQUE FINALE SUR LES DONNEES STRUCTURES 

Meme si le domaine de predilection des donnees structures est la gestion de fichiers, on peut tout a fait y avoir 
recours dans d'autres contextes, et organiser plus systematiquement les variables d'un programme sous la forme de 
telles structures. 

En programmation dite procedural, celle que nous etudions ici, ce type de strategic reste relativement rare. Mais 
rare ne veut pas dire interdit, ou meme inutile. 

Et nous aurons I'occasion de voir qu'en programmation objet, ce type d'organisation des donnees devient 
fondamental. 

Mais ceci est un autre cours... 

7. Recapitulate general 

Lorsqu'on est amene a travailler avec des donnees situees dans un fichier, plusieurs choix, en partie 
independants les uns des autres, doivent etre faits : 

• sur I'organisation en enregistrements du fichier (choix entre fichier texte ou fichier binaire) 

• sur le mode d'acces aux enregistrements du fichier (direct ou sequentiel) 

• sur I'organisation des champs au sein des enregistrements (presence de separateurs ou champs de 
largeur fixe) 

• sur la methode de traitement des informations (recopie integrate prealable du fichier en memoire 
vive ou non) 

• sur le type de variables utilisees pour cette recopie en memoire vive (plusieurs tableaux de type 
simple, ou un seul tableau de type structure). 


Chacune de ces options presente avantages et inconvenients, et il est impossible de donner une regie de 
conduite valable en toute circonstance. II faut connaitre ces techniques, et savoir choisir la bonne option selon le 
probleme a traiter. 

Voici une serie de (pas toujours) petits exercices sur les fichiers texte, que I'on pourra traiter en employant les 
types structures (c'est en tout cas le cas dans les corriges). 

Et en conclusion de la conclusion, voila plusieurs remarques fondamentales : 

REMARQUE N°1 

Lorsqu'on veut recuperer des donnees numeriques inscrites dans un fichier texte, il ne faut surtout pas oublier que 
ces donnees se presentent forcement sous forme de caracteres. La recuperation elle-meme transmettra done 
obligatoirement des donnees de type alphanumerique ; pour utiliser ces donnees a des fins ulterieures de calcul, il 
sera done necessaire d'employer une fonction de conversion. 

Cette remarque ne s'applique evidemment pas aux fichiers binaires. 

REAAARQUE N°1bis 

Voila pourquoi une structure s'appliquant aux fichiers textes est forcement composee uniquement de types 
caracteres. Une structure traitant de fichiers binaires pourrait en revanche etre composee de caracteres, de 
numeriques et de booleens. 

REAAARQUE N°2 

Plusieurs langages interdisent I'ecriture d'une variable structuree dans un fichier texte, ne I'autorisant que pour un 
fichier binaire. 

Si I'on se trouve dans ce cas, cela signifie qu'on peut certes utiliser une structure, ou un tableau de structures, mais 
a condition d'ecrire sur le fichier champ par champ, ce qui annule une partie du benefice de la structure. 

Nous avons postule ici que cette interdiction n'existait pas ; en tenir compte ne changerait pas fondamentalement 
les algorithmes, mais alourdirait un peu le code pour les lignes traitant de I'ecriture dans les fichiers. 


Parti e 1 1 

Procedures et Fonctions 

1. Fonctions personnalisees 

1.1 De quoi s'agit-il ? 

Une application, surtout si elle est longue, a toutes les chances de devoir proceder aux memes traitements, ou a 
des traitements similaires, a plusieurs endroits de son deroulement. Par exemple, la saisie d’une reponse par oui ou 
par non (et le controle qu’elle implique), peuvent etre repetes dix fois a des moments differents de la meme 
application, pour dix questions differentes. 

La maniere la plus evidente, mais aussi la moins habile, de programmer ce genre de choses, c'est bien entendu 
de repeter le code correspondant autant de fois que necessaire. Apparemment, on ne se casse pas la tete : quand il 
faut que la machine interroge I'utilisateur, on recopie les lignes de codes voulues en ne changeant que le 
necessaire, et roule Raoul. Mais en procedant de cette maniere, la pire qui soit, on se prepare des lendemains qui 
dechantent... 

D'abord, parce que si la structure d'un programme ecrit de cette maniere peut paraitre simple, elle est en 
realite inutilement lourdingue. Elle contient des repetitions, et pour peu que le programme soit joufflu, il peut 
devenir parfaitement illisible. Or, le fait d'etre facilement modifiable done lisible, y compris - et surtout - par ceux 
qui ne I'ont pas ecrit est un critere essentiel pour un programme informatique ! Des que I'on programme non pour 
soi-meme, mais dans le cadre d'une organisation (entreprise ou autre), cette necessite se fait sentir de maniere 
aigue. L'ignorer, c'est done forcement grave. 

En plus, a un autre niveau, une telle structure pose des problemes considerables de maintenance : car en cas de 
modification du code, il va falloir traquer toutes les apparitions plus ou moins identiques de ce code pour faire 
convenablement la modification ! Et si I'on en oublie une, patatras, on a laisse un bug. 

Il faut done opter pour une autre strategie, qui consiste a separer ce traitement du corps du programme et a 
regrouper les instructions qui le composent en un module separe. Il ne restera alors plus qu'a appeler ce groupe 
d'instructions (qui n'existe done desormais qu’en un exemplaire unique) a chaque fois qu’on en a besoin. Ainsi, la 
lisibilite est assuree ; le programme devient modulaire, et il suffit de faire une seule modification au bon endroit, 
pour que cette modification prenne effet dans la totalite de I’application. 

Le corps du programme s’appelle alors la procedure principale, et ces groupes d’instructions auxquels on a 
recours s’appellent des fonctions et des sous-procedures (nous verrons un peu plus loin la difference entre ces 
deux termes). 

Reprenons un exemple de question a laquelle I’utilisateur doit repondre par oui ou par non. 

Mauvaise Structure : 


Ecrire "Etes-vous marie ?" 

Repl <- "" 

TantQue Repl <> "Oui" et Repl <> "Non" 
Ecrire "Tapez Oui ou Non" 

Lire Repl 
Fi nTantQue 

Ecrire "Avez-vous des enfants ?" 

Rep2 <- "" 

TantQue Rep2 <> "Oui" et Rep2 <> "Non" 
Ecrire "Tapez Oui ou Non" 

Li re Rep2 
Fi nTantQue 


On le voit bien, il y a la une repetition quasi identique du traitement a accomplir. A chaque fois, on demande 
une reponse par Oui ou Non, avec controle de saisie. La seule chose qui change, c'est le nom de la variable dans 
laquelle on range la reponse. Alors, il doit bien y avoir un true. 

La solution, on vient de le voir, consiste a isoler les instructions demandant une reponse par Oui ou Non, et a 
appeler ces instructions a chaque fois que necessaire. Ainsi, on evite les repetitions inutiles, et on a decoupe notre 
probleme en petits morceaux autonomes. 

Nous allons done creer une fonction dont le role sera de renvoyer la reponse (oui ou non) de I'utilisateur. Ce 
mot de "fonction", en I'occurrence, ne doit pas nous surprendre : nous avons etudie precedemment des fonctions 
fournies avec le langage, et nous avons vu que le but d'une fonction etait de renvoyer une valeur. Eh bien, c'est 
exactement la meme chose ici, sauf que c'est nous qui allons creer notre propre fonction, que nous appellerons 
RepOuiNon : 

Fonction RepOuiNonO en caractere 

True <- "" 

TantQue True <> "Oui" et True <> "Non" 

Ecrire "Tapez Oui ou Non" 

Lire True 
Fi nTantQue 
Renvoyer True 
Fin 

On remarque au passage I’apparition d’un nouveau mot-cle : Renvoyer, qui indique quelle valeur doit prendre 
la fonction lorsqu'elle est utilisee par le programme. Cette valeur renvoyee par la fonction (ici, la valeur de la 
variable True) est en quelque sorte contenue dans le nom de la fonction lui-meme, exactement comme e’etait le 
cas dans les fonctions predefinies. 

Une fonction s'ecrit toujours en-dehors de la procedure principale. Selon les langages, cela peut prendre 
differentes formes. Mais ce qu'il faut comprendre, c'est que ces quelques lignes de codes sont en quelque sorte des 
satellites, qui existent en dehors du traitement lui-meme. Simplement, elles sont a sa disposition, et il pourra y 
faire appel chaque fois que necessaire. Si I'on reprend notre exemple, une fois notre fonction RepOuiNon ecrite, le 
programme principal comprendra les lignes : 

Bonne structure : 


Ecrire "Etes-vous marie ?" 

Repl <- RepOuiNonO 

Ecrire "Avez-vous des enfants ?" 

Rep2 <- RepOuiNonO 

Et le tour est joue ! On a ainsi evite les repetitions inutiles, et si d'aventure, il y avait un bug dans notre 
controle de saisie, il suffirait de faire une seule correction dans la fonction RepOuiNon pour que ce bug soit elimine 
de toute I'application. Elle n'est pas belle, la vie ? 

Toutefois, les plus sagaces d'entre vous auront remarque, tant dans le titre de la fonction que dans chacun des 
appels, la presence de parentheses. Celles-ci, des qu'on declare ou qu'on appelle une fonction, sont obligatoires. 

Et si vous avez bien compris tout ce qui precede, vous devez avoir une petite idee de ce qu'on va pouvoir mettre 
dedans... 

1.2 Passage d'arguments 

Reprenons I’exemple qui precede et analysons-le. On ecrit un message a I'ecran, puis on appelle la fonction 
RepOuiNon pour poser une question ; puis, un peu plus loin, on ecrit un autre message a I'ecran, et on appelle de 
nouveau la fonction pour poser la meme question, etc. C’est une demarche acceptable, mais qui peut encore etre 
amelioree : puisque avant chaque question, on doit ecrire un message, autant que cette ecriture du message figure 
directement dans la fonction appelee. Cela implique deux choses : 


• lorsqu’on appelle la fonction, on doit lui preciser quel message elle doit afficher avant de lire la 
reponse 

• la fonction doit etre « prevenue » qu’elle recevra un message, et etre capable de le recuperer pour 
I’afficher. 

En langage algorithmique, on dira que le message devient un argument (ou un parametre) de la fonction. Cela 
n'est certes pas une decouverte pour vous : nous avons longuement utilise les arguments a propos des fonctions 
predefinies. Eh bien, quitte a construire nos propres fonctions, nous pouvons done construire nos propres 
arguments. Voila comment I’affaire se presente... 

La fonction sera dorenavant declaree comme suit : 

Fonction RepOui Non(Msg en Caractere) en Caractere 
Ecrire Msg 
True <- "" 

TantQue True <> "Oui" et True <> "Non" 

Ecrire "Tapez Oui ou Non" 

Lire True 
Fi nTantQue 
Renvoyer True 
Fin Fonction 

II y a done maintenant entre les parentheses une variable, Msg, dont on precise le type, et qui signale a la 
fonction qu’un argument doit lui etre envoye a chaque appel. Quant a ces appels, justement, ils se simplifieront 
encore dans la procedure principale, pour devenir : 

Repl <- RepOui Non("Etes-vous marie ?") 

Rep2 <- RepOui Non("Avez-vous des enfants ?") 

Et voila le travail. 

Une remarque importante : la, on n'a passe qu’un seul argument en entree. Mais bien entendu, on peut en 
passer autant qu’on veut, et creer des fonctions avec deux, trois, quatre, etc. arguments ; Simplement, il faut 
eviter d'etre gourmands, et il suffit de passer ce dont on en a besoin, ni plus, ni moins ! 

Dans le cas que I'on vient de voir, le passage d'un argument a la fonction etait elegant, mais pas indispensable. 

La preuve, cela marchait deja tres bien avec la premiere version. Mais on peut imaginer des situations ou il faut 
absolument concevoir la fonction de sorte qu'on doive lui transmettre un certain nombre d'arguments si I'on veut 
qu'elle puisse remplir sa tache. Prenons, par exemple, toutes les fonctions qui vont effectuer des calculs. Que 
ceux-ci soient simples ou compliques, il va bien falloir envoyer a la fonction les valeurs grace auxquelles elle sera 
cense produire son resultat (pensez tout betement a une fonction sur le modele d'Excel, telle que celle qui doit 
calculer une somme ou une moyenne). C'est egalement vrai des fonctions qui traiteront des chaTnes de caracteres. 
Bref, dans 99% des cas, lorsqu'on creera une fonction, celle-ci devra comporter des arguments. 

1.3 Deux mots sur I'analyse fonctionnelle 

Comme souvent en algorithmique, si I'on s'en tient a la maniere dont marche I'outil, tout cela n'est en realite pas 
tres complique. Les fonctions personnalisees se deduisent tres logiquement de la maniere nous nous avons deja 
experiments les fonctions predefinies. 

Le plus difficile, mais aussi le plus important, c'est d'acquerir le reflexe de constituer systematiquement les 
fonctions adequates quand on doit traiter un probleme donne, et de flairer la bonne maniere de decouper son 
algorithme en differentes fonctions pour le rendre leger, lisible et performant. 

Cette partie de la reflexion s'appelle d'ailleurs I'analyse fonctionnelle d'un probleme, et c'est toujours par elle 
qu'il faut commencer : en gros, dans un premier temps, on decoupe le traitement en modules (algorithmique 
fonctionnelle), et dans un deuxieme temps, on ecrit chaque module (algorithmique classique). Cependant, avant 


d'en venir la, il nous faut decouvrir deux autres outils, qui prennent le relais la ou les fonctions deviennent 
incapables de nous aider. 

2. Sous-Procedures 

2.1 Generalities 

Les fonctions, c'est bien, mais dans certains cas, ca ne nous rend guere service. 

II peut en effet arriver que dans un programme, on ait a realiser des taches repetitives, mais que ces taches 
n'aient pas pour role de generer une valeur particuliere, ou qu'elles aient pour role d'en generer plus d'une a la fois. 
Vous ne voyez pas de quoi je veux parler ? Prenons deux exemples. 

Premier exemple. Imaginons qu'au cours de mon application, j'aie plusieurs fois besoin d'effacer I'ecran et de 
reafficher un bidule comme un petit logo en haut a gauche. On pourrait se dire qu'il faut creer une fonction pour 
faire cela. Mais quelle serait la valeur renvoyee par la fonction ? Aucune ! Effacer I'ecran, ce n'est pas produire un 
resultat stockable dans une variable, et afficher un logo non plus. Voila done une situation ou j'ai besoin de repeter 
du code, mais ou ce code n'a pas comme role de produire une valeur. 

Deuxieme exemple. Au cours de mon application, je dois plusieurs fois faire saisir un tableau d'entiers (mais a 
chaque fois, un tableau different). La encore, on serait tente d'effectuer toutes ces saisies de tableaux dans une 
seule fonction. Mais probleme, une fonction ne peut renvoyer qu'une seule valeur a la fois. Elle ne peut done 
renvoyer un tableau, qui est une serie de valeurs distinctes. 

Alors, dans ces deux cas, faute de pouvoir traiter I'affaire par une fonction, devra-t-on en rester au code 
repetitif dont nous venons de denoncer si vigoureusement les faiblesses ? Mmmmmh ? Vous vous doutez bien que 
non. Heureusement, tout est prevu, il y a une solution. Et celle-ci consiste a utiliser des sous-procedures. 

En fait, les fonctions - que nous avons vues - ne sont finalement qu'un cas particulier des sous-procedures - 
que nous allons voir : celui oil doit etre renvoye vers la procedure appelante une valeur et une seule. Dans tous 
les autres cas (celui ou on ne renvoie aucune valeur, comme celui ou en en renvoie plusieurs), il faut done avoir 
recours non a la forme particuliere et simplifiee (la fonction), mais a la forme generate (la sous-procedure). 

Parlons done de ce qui est commun aux sous-procedures et aux fonctions, mais aussi de ce qui les differencie. 
Voici comment se presente une sous-procedure : 

Procedure BiduleC ... ) 

Fin Procedure 

Dans la procedure principale, I’appel a la sous-procedure Bidule devient quant a lui : 

Appel er BiduleC. . .) 

Etablissons un premier etat des lieux. 

• Alors qu'une fonction se caracterisait par les mots-cles Fonction ... Fin Fonction, une sous- 
procedure est identifiee par les mots-cles Procedure ... Fin Procedure. Oui, je sais, c'est un peu trivial 
comme remarque, mais, bon, on ne sait jamais. 

• Lorsqu'une fonction etait appelee, sa valeur (retournee) etait toujours affectee a une variable (ou 
integree dans le calcul d'une expression). L'appel a une procedure, lui, est au contraire toujours une 
instruction autonome. "Execute la procedure Bidule" est un ordre qui se suffit a lui-meme. 

• Toute fonction devait, pour cette raison, comporter I'instruction "Renvoyer". Pour la meme raison, 
I'instruction "Renvoyer" n'est jamais utilisee dans une sous-procedure. La fonction est une valeur 
calculee, qui renvoie son resultat vers la procedure principale. La sous-procedure, elle, est un traitement ; 
elle ne "vaut" rien. 

• Meme une fois qu'on a bien compris les trois premiers points, on n'est pas completement au bout de 


nos peines. 


2.2 Le probleme des arguments 

En effet, il nous reste a examiner ce qui peut bien se trouver dans les parentheses, a la place des points de 
suspension, aussi bien dans la declaration de la sous-procedure que dans I'appel. Vous vous en doutez bien : c'est la 
que vont se trouver les outils qui vont permettre I'echange d'informations entre la procedure principale et la sous- 
procedure (en fait, cette derniere phrase est trap restrictive : mieux vaudrait dire : entre la procedure appelante 
et la procedure appelee. Car une sous-procedure peut tres bien en appeler elle-meme une autre afin de pouvoir 
accomplir sa tache) 

De meme qu'avec les fonctions, les valeurs qui circulent depuis la procedure (ou la fonction) appelante vers la 
sous-procedure appelee se nomment des arguments, ou des parametres en entree de la sous-procedure. Comme 
on le voit, qu'il s'agisse des sous-procedure ou des fonctions, ces choses jouant exactement le meme role 
(transmettre une information depuis le code donneur d'ordres jusqu'au code sous-traitant), elle portent egalement 
le meme nom. Unique petite difference, on a precise cette fois qu'il s'agissait d'arguments, ou de parametres, en 
entree. Pourquoi done ? 

Tout simplement parce que que dans une sous-procedure, on peut etre amene a vouloir renvoyer des resultats 
vers le programme principal ; or, la, a la difference des fonctions, rien n'est prevu : la sous-procedure, en tant que 
telle, ne "renvoie" rien du tout (comme on vient de le voir, elle est d'ailleurs depourvue de I'instruction "renvoyer"). 
Ces resultats que la sous-procedure doit transmettre a la procedure appelante devront done eux aussi etre 
vehicules par des parametres. Mais cette fois, il s'agira de parametres fonctionnant dans I'autre sens (du sous- 
traitant vers le donneur d'ordres) : on les appellera done des parametres en sortie. 

Ceci nous permet de reformuler en d'autres termes la verite fondamentale apprise un peu plus haut : toute 
sous-procedure possedant un et un seul parametre en sortie peut egalement etre ecrite sous forme d'une 
fonction (et entre nous, c'est une formulation preferable car un peu plus facile a comprendre et done a retenir). 

Jusque la, ca va ? Si oui, prenez un cachet d'aspirine et poursuivez la lecture. Si non, prenez un cachet d'aspirine 
et recommencez depuis le debut. Et dans les deux cas, n'oubliez pas le grand verre d'eau pour faire passer 
I'aspirine. 

Il nous reste un detail a examiner, detail qui comme vous vous en doutez bien, a une certaine importance : 
comment fait-on pour faire comprendre a un langage quels sont les parametres qui doivent fonctionner en entree 
et quels sont ceux qui doivent fonctionner en sortie... 

2.3 Comment qa marche tout 9 a ? 

En fait, si je dis qu'un parametre est "en entree" ou "en sortie", j'enonce quelque chose a propos de son role dans 
le programme. Je dis ce que je souhaite qu'il fasse, la maniere dont je veux qu'il se comporte. Mais les programmes 
eux-memes n'ont cure de mes desirs, et ce n'est pas cette classification qu'ils adoptent. C'est toute la difference 
entre dire qu'une prise electrique sert a brancher un rasoir ou une cafetiere (ce qui caracterise son role), et dire 
qu'elle est en 220 V ou en 110 V (ce qui caracterise son type technique, et qui est I'information qui interesse 
I'electricien). A I'image des electriciens, les langages se contrefichent de savoir quel sera le role (entree ou sortie) 
d'un parametre. Ce qu'ils exigent, c'est de connaitre leur voltage... pardon, le mode de passage de ces parametres. 
Il n'en existe que deux : 

• le passage par valeur 

• le passage par reference 

...Voyons de plus pres de quoi il s'agit. 

Reprenons I'exemple que nous avons deja utilise plus haut, celui de notre fonction RepOuiNon. Comme nous 
I'avons vu, rien ne nous empeche de reecrire cette fonction sous la forme d'une procedure (puisqu'une fonction 
n'est qu'un cas particulier de sous-procedure). Nous laisserons pour Tinstant de cote la question de savoir comment 



renvoyer la reponse (contenue dans la variable True) vers le programme principal. En revanche, nous allons 
declarer que Msg est un parametre dont la transmission doit se faire par valeur. Cela donnera la chose suivante : 
Procedure RepOuiNon(Msg en Caractere par valeur) 

Ecrire Msg 
True <- "" 

TantQue True <> "Oui" et True <> "Non" 

Ecrire "Tapez Oui ou Non" 

Lire True 
Fi nTantQue 

??? Comment transmettre True a la procedure appelante ??? 

Fin Procedure 

Quant a I'appel a cette sous-procedure, il pourra prendre par exemple cette forme : 

M <- "Etes-vous marie ?" 

Appel er RepOuiNon(M) 

Que va-t-il se passer ? 

Lorsque le programme principal arrive sur la premiere ligne, il affecte la variable M avec le libelle "Etes-vous 
marie". La ligne suivante declenche I'execution de la sous-procedure. Celle-ci cree aussitot une variable Msg. Celle- 
ci ayant ete declaree comme un parametre passe par valeur, Msg va etre affecte avec le meme contenu que M. 

Cela signifie que Msg est dorenavant une copie de M. Les informations qui etaient contenues dans M ont ete 
integralement recopiees (en double) dans Msg. Cette copie subsistera tout au long de I'execution de la sous- 
procedure RepOuiNon et sera detruite a la fin de celle-ci. 

Une consequence essentielle de tout cela est que si d'aventure la sous-procedure RepOuiNon contenait une 
instruction qui modifiait le contenu de la variable Msg, cela n'aurait aucune espece de repercussion sur la 
procedure principale en general, et sur la variable M en particulier. La sous-procedure ne travaillant que sur une 
copie de la variable qui a ete fournie par le programme principal, elle est incapable, meme si on le souhaitait, 
de modifier la valeur de celle-ci. Dit d'une autre maniere, dans une procedure, un parametre passe par valeur ne 
peut etre qu'un parametre en entree. 

C'est en meme temps une limite (aggravee par le fait que les informations ainsi recopiees occupent dorenavant 
deux fois plus de place en memoire) et une securite : quand on transmet un parametre par valeur, on est sur et 
certain que meme en cas de bug dans la sous-procedure, la valeur de la variable transmise ne sera jamais modifiee 
par erreur (e'est-a-dire ecrasee) dans le programme principal. 

Admettons a present que nous declarions un second parametre, True, en precisant cette fois qu'il sera transmis 
par reference. Et adoptons pour la procedure I'ecriture suivante : 

Procedure RepOuiNon(Msg en Caractere par valeur, True en Caractere par reference) 

Ecrire Msg 

True <- "" 

TantQue True <> "Oui" et True <> "Non" 

Ecrire "Tapez Oui ou Non" 

Lire True 
Fi nTantQue 
Fin Fonction 

L'appel a la sous-procedure deviendrait par exemple : 

M «- "Etes-vous marie ?" 

Appel er RepOuiNon(M, T) 

Ecrire "votre reponse est ", T 

Depiautons le mecanisme de cette nouvelle ecriture. En ce qui concerne la premiere ligne, celle qui affecte la 
variable M, rien de nouveau sous le soleil. Toutefois, I'appel a la sous-procedure provoque deux effets tres 
differents. Comme on I'a deja dit, la variable Msg est creee et immediatement affectee avec une copie du contenu 
de M, puisqu'on a exige un passage par valeur. Mais en ce qui concerne True, il en va tout autrement. Le fait qu'il 
s'agisse cette fois d'un passage par reference fait que la variable True ne contiendra pas la valeur de T, mais son 
adresse, e'est-a-dire sa reference. 


Des lors, toute modification de True sera immediatement redirigee, par ricochet en quelque sorte, sur T. 

True n'est pas une variable ordinaire : elle ne contient pas de valeur, mais seulement la reference a une valeur, qui 
elle, se trouve ailleurs (dans la variable T). II s'agit done d'un genre de variable completement nouveau, et 
different de ce que nous avons vu jusque la. Ce type de variable porte un nom : on I'appelle un pointeur. Tous les 
parametres passes par reference sont des pointeurs, mais les pointeurs ne se limitent pas aux parametres passes 
par reference (meme si ce sont les seuls que nous verrons dans le cadre de ce cours). II faut bien comprendre que 
ce type de variable etrange est gere directement par les langages : a partir du moment oil une variable est 
consideree comme un pointeur, toute affectation de cette variable se traduit automatiquement par la 
modification de la variable sur laquelle elle pointe. 

Passer un parametre par reference, cela presente done deux avantages. Et d'une, on gagne en occupation de 
place memoire, puisque le parametre en question ne recopie pas les informations envoyees par la procedure 
appelante, mais qu'il se contente d'en noter I'adresse. Et de deux, cela permet d'utiliser ce parametre tant en 
lecture (en entree) qu'en ecriture (en sortie), puisque toute modification de la valeur du parametre aura pour 
effet de modifier la variable correspondante dans la procedure appelante. 

Nous pouvons resumer tout cela par un petit tableau : 



passage par valeur 

passage par reference 

utilisation en entree 

oui 

oui 

utilisation en sortie 

non 

oui 


Mais alors, demanderez-vous dans un elan de touchante naivete, si le passage par reference presente les deux 
avantages presentes il y a un instant, pourquoi ne pas s'en servir systematiquement ? Pourquoi s'embeter avec les 
passages par valeur, qui non seulement utilisent de la place en memoire, mais qui de surcroit nous interdisent 
d'utiliser la variable comme un parametre en sortie ? 

Eh bien, justement, parce qu'on ne pourra pas utiliser comme parametre en sortie, et que cet inconvenient se 
revele etre aussi, eventuellement, un avantage. Disons la chose autrement : e'est une securite. C'est la garantie 
que quel que soit le bug qui pourra affecter la sous-procedure, ce bug ne viendra jamais mettre le foutoir dans les 
variables du programme principal qu'elle ne doit pas toucher. Voila pourquoi, lorsqu'on souhaite definir un 
parametre dont on sait qu'il fonctionnera exclusivement en entree, il est sage de le verrouiller, en quelque sorte, 
en le definissant comme passe par valeur. Et Lycee de Versailles, ne seront definis comme passes par reference que 
les parametres dont on a absolument besoin qu'ils soient utilises en sortie. 

3. Variables publiques et privees 

Resumons la situation. Nous venons de voir que nous pouvions decouper un long traitement comportant 
eventuellement des redondances (notre application) en differents modules. Et nous avons vu que les informations 
pouvaient etre transmises entre ces modules selon deux modes : 

• si le module appele est une fonction, par le retour du resultat 

• dans tous les cas, par la transmission de parametres (que ces parametres soient passes par valeur 
ou par reference) 

En fait, il existe un troisieme et dernier moyen d'echanger des informations entre differentes procedures et 
fonctions : c'est de ne pas avoir besoin de les echanger, en faisant en sorte que ces procedures et fonctions 
partagent litteralement les memes variables. Cela suppose d'avoir recours a des variables particulieres, lisibles et 
utilisables par n'importe quelle procedure ou fonction de I'application. 

Par defaut, une variable est declaree au sein d'une procedure ou d'une fonction. Elle est done creee avec cette 
procedure, et disparait avec elle. Durant tout le temps de son existence, une telle variable n'est visible que par la 
procedure qui I'a vu naitre. Si je cree une variable Toto dans une procedure Bidule, et qu'en cours de route, ma 


procedure Bidule appelle une sous-procedure Machin, il est hors de question que Machin puisse acceder a Toto, ne 
serait-ce que pour connaitre sa valeur (et ne parlons pas de la modifier). Voila pourquoi ces variables par defaut 
sont dites privees, ou locales. 

Mais a cote de cela, il est possible de creer des variables qui certes, seront declarees dans une procedure, mais 
qui du moment ou elles existeront, seront des variables communes a toutes les procedures et fonctions de 
I'application. Avec de telles variables, le probleme de la transmission des valeurs d'une procedure (ou d'une 
fonction) a I'autre ne se pose meme plus : la variable True, existant pour toute I'application, est accessible et 
modifiable depuis n'importe quelle ligne de code de cette application. Plus besoin done de la transmettre ou de la 
renvoyer. Une telle variable est alors dite publique, ou globale. 

La maniere dont la declaration d'une variable publique doit etre faites est evidemment fonction de chaque 
langage de programmation. En pseudo-code algorithmique, on pourra utiliser le mot-cle Publique : 

Variable Publique Toto en Numerique 

Alors, pourquoi ne pas rendre toutes les variables publiques, et s'epargner ainsi de fastidieux efforts pour passer 
des parametres ? C’est tres simple, et e'est toujours la meme chose : les variables globales consomment 
enormement de ressources en memoire. En consequence, le principe qui doit presider au choix entre variables 
publiques et privees doit etre celui de I’economie de moyens : on ne declare comme publiques que les variables 
qui doivent absolument I’etre. Et chaque fois que possible, lorsqu’on cree une sous-procedure, on utilise le passage 
de parametres plutot que des variables publiques. 

4. PEUT-ON TOUT FAIRE ? 

A cette question, la reponse est bien evidemment : oui, on peut tout faire. Mais e'est precisement la raison pour 
laquelle on peut vite en arriver a faire aussi absolument n'importe quoi. 

N'importe quoi, e'est quoi ? C'est par exemple, comme on vient de le voir, mettre des variables globales partout, 
sous pretexte que e'est autant de parametres qu'on n'aura pas a passer. 

Mais on peut imaginer d'autres atrocites. 

Par exemple, une fonction, dont un des parametres d'entree serait passe par reference, et modifie par la 
fonction. Ce qui signifierait que cette fonction produirait non pas un, mais deux resultats. Autrement dit, que sous 
des dehors de fonctions, elle se comporterait en realite comme une sous-procedure. 

Ou inversement, on peut concevoir une procedure qui modifierait la valeur d'un parametre (et d'un seul) passe 
par reference. Il s'agirait la d'une procedure qui en realite, serait une fonction. Quoique ce dernier exemple ne soit 
pas d'une gravite dramatique, il participe de la meme logique consistant a embrouiller le code en faisant passer un 
outil pour un autre, au lieu d'adopter la structure la plus claire et la plus lisible possible. 

Enfin, il ne faut pas ecarter la possibility de programmeurs particulierement vicieux, qui par un savant melange 
de parametres passes par reference, de variables globales, de procedures et de fonctions mal choisies, finiraient 
par accoucher d'un code absolument illogique, illisible, et dans lequel la chasse a I'erreur releverait de I'exploit. 

Trefle de plaisanteries : le principe qui doit guider tout programmeur est celui de la solidite et de la clarte du 
code. Une application bien programmee est une application a ('architecture claire, dont les differents modules 
font ce qu'ils disent, disent ce qu'il font, et peuvent etre testes (ou modifies) un par un sans perturber le reste 
de la construction. Il convient done : 

1. de limiter au minimum I'utilisation des variables globales. Celles-ci doivent etre employees avec 
nos celebres amis italo-armeniens, e'est-a-dire avec parcimonie et a bon escient. 

2. de regrouper sous forme de modules distincts tous les morceaux de code qui possedent une 
certaine unite fonctionnelle (programmation par "blocs"). C'est-a-dire de faire la chasse aux lignes de codes 
redondantes, ou quasi-redondantes. 

3. de faire de ces modules des fonctions lorsqu'ils renvoient un resultat unique, et des sous- 
procedures dans tous les autres cas (ce qui implique de ne jamais passer un parametre par reference a 
une fonction : soit on n'en a pas besoin, soit on en a besoin, et ce n'est alors plus une fonction). 


Respecter ces regies d'hygiene est indispensable si I'on veut qu'une application ressemble a autre chose qu'au 
palais du facteur Cheval. Car une architecture a laquelle on ne comprend rien, c'est sans doute tres poetique, mais 
il y a des circonstances ou I'efficacite est preferable a la poesie. Et, pour ceux qui en douteraient encore, la 
programmation informatique fait (helas ?) partie de ces circonstances. 

5. Algorithmes fonctionnels 

Pour clore ce chapitre, void quelques mots supplementaires a propos de la structure generate d’une 
application. Comme on I'a dit a plusieurs reprises, celle-ci va couramment etre formee d’une procedure principale, 
et de fonctions et de sous-procedures (qui vont au besoin elles-memes en appeler d’autres, etc.). L’exemple 
typique est celui d’un menu, ou d’un sommaire, qui « branche » sur differents traitements, done differentes sous- 
procedures. 

L’algorithme fonctionnel de I’application est le decoupage et/ou la representation graphique de cette 
structure generate, ayant comme objectif de faire comprendre d’un seul coup d’oeil quelle procedure fait quoi, et 
quelle procedure appelle quelle autre. L’algorithme fonctionnel est done en quelque sorte la construction du 
squelette de I’application. II se situe a un niveau plus general, plus abstrait, que I’algorithme normal, qui lui, 
detaille pas a pas les traitements effectues au sein de chaque procedure. 

Dans la construction - et la comprehension - d’une application, les deux documents sont indispensables, et 
constituent deux etapes successives de I’elaboration d’un projet. La troisieme - et derniere - etape, consiste a 
ecrire, pour chaque procedure et fonction, I’algorithme detaille. 

Exemple de realisation d’un algorithme fonctionnel : Le Jeu du Pendu 

Vous connaissez tous ce jeu : I’utilisateur doit deviner un mot choisi au hasard par I’ordinateur, en un minimum 
d’essais. Pour cela, il propose des lettres de I’alphabet. Si la lettre figure dans le mot a trouver, elle s’affiche. Si 
elle n’y figure pas, le nombre des mauvaises reponses augmente de 1. Au bout de dix mauvaises reponses, la partie 
est perdue. 

Ce petit jeu va nous permettre de mettre en relief les trois etapes de la realisation d’un algorithme un peu 
complexe ; bien entendu, on pourrait toujours ignorer ces trois etapes, et se lancer comme un derate directement 
dans la gueule du loup, a savoir I’ecriture de I’algorithme definitif. Mais, sauf a etre particulierement doue, mieux 
vaut respecter le canevas qui suit, car les difficultes se resolvent mieux quand on les saucissonne... 

Etape 1 : le dictionnaire des donnees 

Le but de cette etape est d’identifier les informations qui seront necessaires au traitement du probleme, et de 
choisir le type de codage qui sera le plus satisfaisant pour traiter ces informations. C’est un moment essentiel de la 
reflexion, qu’il ne faut surtout pas prendre a la legere... Or, neuf programmeurs debutants sur dix baclent cette 
reflexion, quand ils ne la zappent pas purement et simplement. La punition ne se fait generalement pas attendre 
longtemps ; I’algorithme etant bati sur de mauvaises fondations, le programmeur se rend compte tout en I’ecrivant 
que le choix de codage des informations, par exemple, mene a des impasses. La precipitation est done punie par le 
fait qu’on est oblige de tout reprendre depuis le debut, et qu’on a au total perdu bien davantage de temps qu’on 
en a cru en gagner... 

Done, avant meme d’ecrire quoi que ce soit, les questions qu’il faut se poser sont les suivantes : 

• de quelles informations le programme va-t-il avoir besoin pour venir a bout de sa tache ? 

• pour chacune de ces informations, quel est le meilleur codage ? Autrement dit, celui qui sans 
gaspiller de la place memoire, permettra d’ecrire I’algorithme le plus simple ? 

Encore une fois, il ne faut pas hesiter a passer du temps sur ces questions, car certaines erreurs, ou certains 
oublis, se payent cher par la suite. Et inversement, le temps investi a ce niveau est largement rattrape au moment 
du developpement proprement dit. 



Pour le jeu du pendu, void la liste des informations dont on va avoir besoin : 


• une liste de mots (si I’on veut eviter que le programme ne propose toujours le meme mot a trouver, 
ce qui risquerait de devenir assez rapidement lassant...) 

• le mot a deviner 

• la lettre proposee par le joueur a chaque tour 

• le nombre actuel de mauvaises reponses 

• et enfin, last but not least, I’ensemble des lettres deja trouvees par le joueur. Cette information 
est capitale ; le programme en aura besoin au moins pour deux choses : d’une part, pour savoir si le mot 
entier a ete trouve. D’autre part, pour afficher a chaque tour I’etat actuel du mot (je rappelle qu’a chaque 
tour, les lettres trouvees sont affichees en clair par la machine, les lettres restant a deviner etant 
remplacees par des tirets). 

• a cela, on pourrait ajouter une liste comprenant I’ensemble des lettres deja proposees par le 
joueur, qu’elles soient correctes ou non ; ceci permettra d’interdire au joueur de proposer a nouveau une 
lettre precedemment jouee. 

Cette liste d’informations n’est peut-etre pas exhaustive ; nous aurons vraisemblablement besoin au cours de 
I’algorithme de quelques variables supplementaires (des compteurs de boucles, des variables temporaires, etc.). 
Mais les informations essentielles sont bel et bien la. Se pose maintenant le probleme de choisir le mode de codage 
le plus fute. Si, pour certaines informations, la question va etre vite reglee, pour d’autres, il va falloir faire des 
choix (et si possible, des choix intelligents !). C’est parti, mon kiki : 

• Pour la liste des mots a trouver, il s’agit d’un ensemble d’informations de type alphanumerique. 

Ces informations pourraient faire partie du corps de la procedure principale, et etre ainsi stockees en 
memoire vive, sous la forme d’un tableau de chaTnes. Mais ce n’est certainement pas le plus judicieux. 
Toute cette place occupee risque de peser lourd inutilement, car il n’y a aucun interet a stocker 
I’ensemble des mots en memoire vive. Et si I’on souhaite enrichir la liste des mots a trouver, on sera oblige 
de reecrire des lignes de programme... Conclusion, la liste des mots sera bien plus a sa place dans un fichier 
texte, dans lequel le programme ira piocher un seul mot, celui qu’il faudra trouver. Nous constituerons 
done un fichier texte, appele dico.txt, dans lequel figurera un mot par ligne (par enregistrement). 

• Le mot a trouver, lui, ne pose aucun probleme : il s’agit d’une information simple de type chaine, 
qui pourra etre stocke dans une variable appelee mot, de type caractere. 

• De meme, la lettre proposee par le joueur est une information simple de type chaine, qui sera 
stockee dans une variable appelee lettre, de type caractere. 

• Le nombre actuel de mauvaises reponses est une information qui pourra etre stockee dans une 
variable numerique de type entier simple appelee MovRep. 

• L’ensemble des lettres trouvees par le joueur est typiquement une information qui peut faire 
I’objet de plusieurs choix de codage ; rappelons qu’au moment de I’affichage, nous aurons besoin de savoir 
pour chaque lettre du mot a deviner si elle a ete trouvee ou non. Une premiere possibility, immediate, 
serait de disposer d’une chaine de caracteres comprenant I’ensemble des lettres precedemment trouvees. 
Cette solution est loin d’etre mauvaise, et on pourrait tout a fait I’adopter. Mais ici, on fera une autre 
choix, ne serait-ce que pour varier les plaisirs : on va se doter d’un tableau de booleens, comptant autant 
d’emplacements qu’il y a de lettres dans le mot a deviner. Chaque emplacement du tableau correspondra a 
une lettre du mot a trouver, et indiquera par sa valeur si la lettre a ete decouverte ou non (faux, la lettre 
n’a pas ete devinee, vrai, elle I’a ete). La correspondance entre les elements du tableau et le mot a 
deviner etant immediate, la programmation de nos boucles en sera facilitee. Nous baptiserons notre 
tableau de booleens du joli nom de « verif ». 



• Enfin, I’ensemble des lettres proposees sera stockee sans soucis dans une chatne de caracteres 
nommee Propos. 

Nous avons maintenant suffisamment gamberge pour dresser le tableau final de cette etape, a savoir le 
dictionnaire des donnees proprement dit : 


Nom 

Type 

Description 

Dico.txt 

Fichier texte 

Liste des mots a deviner 

Mot 

Caractere 

Mot a deviner 

Lettre 

Caractere 

Lettre proposee 

MovRep 

Entier 

Nombre de mauvaises reponses 

Verif() 

Tableau de Booleens 

Lettres precedemment devinees, en correspondance avec 
Mot 

Propos 

Caractere 

Liste des lettres proposees 


Etape 2 : I’algorithme fonctionnel 

On peut a present passer a la realisation de I’algorithme fonctionnel, c’est-a-dire au decoupage de notre 
probleme en blocs logiques. Le but de la manoeuvre est multiple : 

• faciliter la realisation de I’algorithme definitif en le tronconnant en plus petits morceaux. 

• Gagner du temps et de la legerete en isolant au mieux les sous-procedures et fonctions qui meritent 
de I’etre. Eviter ainsi eventuellement des repetitions multiples de code au cours du programme, repetitions 
qui ne different les unes des autres qu'a quelques variantes pres. 

• Permettre une division du travail entre programmeurs, chacun se voyant assigner la programmation 
de sous-procedures ou de fonctions specifiques (cet aspect est essentiel des qu’on quitte le bricolage 
personnel pour entrer dans le monde de la programmation professionnelle, done collective). 

Dans notre cas precis, un premier bloc se detache : il s’agit de ce qu’on pourrait appeler les preparatifs du jeu 
(choix du mot a deviner). Puisque le but est de renvoyer une valeur et une seule (le mot choisi par la machine), 
nous pouvons confier cette tache a une fonction specialisee ChoixDuMot (a noter que ce decoupage est un choix de 
lisibilite, et pas une necessite absolue ; on pourrait tout aussi bien faire cela dans la procedure principale). 

Cette procedure principale, justement, va ensuite avoir necessairement la forme d’une boucle Tantque : en 
effet , tant que la partie n’est pas finie, on recommence la serie des traitements qui representent un tour de jeu. 
Mais comment, justement, savoir si la partie est finie ? Elle peut se terminer soit parce que le nombre de mauvaises 
reponses a atteint 10, soit parce que toutes les lettres du mot ont ete trouvees. Le mieux sera done de confier 
I’examen de tout cela a une fonction specialisee, PartieFinie, qui renverra une valeur numerique (0 pour signifier 
que la partie est en cours, 1 en cas de victoire, 2 en cas de defaite). 

Passons maintenant au tour de jeu. 

La premiere chose a faire, e’est d’afficher a I’ecran I’etat actuel du mot a deviner : un melange de lettres en 
clair (celles qui ont ete trouvees) et de tirets (correspondant aux lettres non encore trouvees). Tout ceci pourra 
etre pris en charge par une sous-procedure specialisee, appelee AffichageMot. Quant a l ’ i ni tiali sation des 
differentes variables, elle pourra etre placee, de maniere classique, dans la procedure principale elle-meme. 

Ensuite, on doit proceder a la saisie de la lettre proposee, en veillant a effectuer les controles de saisie 
adequats. La encore, une fonction specialisee, SaisieLettre, sera toute indiquee. 

Une fois la proposition faite, il convient de verifier si elle correspond ou non a une lettre a deviner, et a en tirer 
les consequences. Ceci sera fait par une sous-procedure appelee VerifLettre. 






Enfin, une fois la partie terminee, on doit afficher les conclusions a I’ecran ; on declare a cet effet une derniere 
procedure, FinDePartie. 

Nous pouvons, dans un algorithme fonctionnel complet, dresser un tableau des differentes procedures et 
fonctions, exactement comme nous I’avons fait juste avant pour les donnees (on s’epargnera cette peine dans le 
cas present, ce que nous avons ecrit ci-dessus suffisant amplement. Mais dans le cas d’une grosse application, un 
tel travail serait necessaire et nous epargnerait bien des soucis). 

On peut aussi schematiser le fonctionnement de notre application sous forme de blocs, chacun des blocs 
representant une fonction ou une sous-procedure : 

A ce stade, I’analyse dite fonctionnelle est terminee. Les fondations (solides, esperons-le) sont posees pour 
finaliser I’application. 

Etape 3 : Algorithmes detailles 

Normalement, il ne nous reste plus qu’a traiter chaque procedure isolement. On commencera par les sous- 
procedures et fonctions, pour terminer par la redaction de la procedure principale. 

ATTENTION ! les liens ci-dessous menent directement aux corriges ! 

Fonction ChoixDuMot 
Fonction PartieFinie 
Procedure AffichageMot 
Procedure SaisieLettre 
Procedure VerifLettre 
Procedure Epilogue 
Procedure Principale 


Parti e 12 

Notions Complementaires 

Une fois n’est pas coutume, ce chapitre ne sera I’objet d’aucun exercice. Cela ne veut pas dire pour autant que 
ce qui s’y trouve n’est pas interessant. 

Non mais des fois. 

1. Programmation structuree 

Petit retour sur une notion tres rapidement survolee plus haut : celle de « programmation structuree ». En fait, 
nous avons jusqu’a present, tels Monsieur Jourdain, fait de la programmation structuree sans le savoir. Aussi, plutot 
qu’expliquer longuement en quoi cela consiste, je prefere prendre le probleme par I'autre bout : en quoi cela ne 
consiste pas. 

Dans certains langages (historiquement, ce sont souvent des langages anciens), les lignes de programmation 
portent des numeros. Et les lignes sont executees par la machine dans I’ordre de ces numeros. Jusqu’ici, en soi, pas 
de probleme. Mais I’astuce est que tous ces langages, il existe une instruction de branchement, notee aller a en 
pseudo-code, instruction qui envoie directement le programme a la ligne specifiee. Inversement, ce type de 
langage ne comporte pas d ’instructions comme FinTantQue, ou FinSi, qui « ferment » un bloc. 

Prenons I’exemple d’une structure « Si ... Alors ... Sinon » 

Programmation structuree 
Si condition Alors 
instructions 1 
Si non 

instructions 2 

Fi nSi 

Programmation non structuree 

1000 Si condition Alors Aller En 1200 

1100 instruction 1 

1110 etc. 

1120 etc. 

1190 Aller en 1400 
1200 instruction 2 
1210 etc. 

1220 etc. 

1400 suite de l’algorithme 

Vous voyez le topo : un programme ecrit dans ce type de langages se presente comme une suite de 
branchements emmeles les uns dans les autres. D’une part, on ne peut pas dire que cela favorise la lisibilite du 
programme. D’autre part, c’est une source importante d’erreurs, car tot ou tard on oublie un « aller a », ou on un 
met un de trap, etc. A fortiori lorsqu’on complique un algorithme existant, cela peut devenir un jungle 
inextricable. 

A I’inverse, la programmation structuree, surtout si I’on prend soin de rationaliser la presentation en mettant 
des lignes de commentaires et en pratiquant [’indentation, evite des erreurs, et revele sa structure logique de 
maniere tres claire. 

Le danger est que si la plupart des langages de programmation utilises sont structures, ils offrent tout de meme 
la plupart du temps la possibility de pratiquer la programmation non structuree. Dans ce cas, les lignes ne sont pas 
designees par des numeros, mais certaines peuvent etre reperees par des noms (dits « etiquettes ») et on dispose 
d’une instruction de branchement. 



Autrement dit, meme quand un langage vous offre une possibility de faire des entorses a la programmation 
structuree, il ne faut s’en saisir sous aucun pretexte. 



2. Interpretation et compilation 

Avec ce paragraphe, on sort un peu de I’algorithmique proprement dite pour entrer dans le domaine plus 
technique de la realisation pratique. Ou, si I’on prSfSre, ces derniSres lignes sont I’apothSose, le bouquet final, 
I’extase ultime, la consecration grandiose, de ce cours. 

En toute modestie, bien sur. 

Jusqu’ici, nous avons travaillS sur la premiere Stape de la realisation d’un programme : la redaction de 
I'algorithme. 



En fait, si I’algorithme est bien Scrit, sans faute logique, I’Stape suivante ne doit normalement poser aucun 
problSme conceptuel. II n'y a plus qu'a effectuer une simple traduction. 



A partir de la, le travail du programmeur est virtuellement terminS (en rSalitS, il reste tout de meme une 
inevitable phase de tests, de corrections, etc., qui s'avSre souvent trSs longue). Mais en tout cas, pour I’ordinateur, 
c’est la que les ennuis commencent. En effet, aucun ordinateur n’est en soi apte a exScuter les instructions telles 
qu’elles sont redigees dans tel ou tel langage ; I’ordinateur, lui, ne comprend qu’un seul langage, qui est un 
langage code en binaire (a la rigueur en hexadecimal) et qui s’appelle le langage machine (ou assembleur). 



C’est a cela que sert un langage : a vous Spargner la programmation en binaire (une pure horreur, vous vous en 
doutez) et vous permettre de vous faire comprendre de I’ordinateur d’une maniSre (relativement) lisible. 

C’est pourquoi tout langage, a partir d’un programme ecrit, doit obligatoirement procSder a une traduction en 
langage machine pour que ce programme soit executable. 

II existe deux strategies de traduction, ces deux strategies Stant parfois disponibles au sein du meme langage. 

• le langage traduit les instructions au fur et a mesure qu’elles se prSsentent. Cela s’appelle la 

compilation a la volee, ou (’interpretation. 

• le langage commence par traduire I’ensemble du programme en langage machine, constituant ainsi 
un deuxiSme programme (un deuxiSme fichier) distinct physiquement et logiquement du premier. Ensuite, 
et ensuite seulement, il execute ce second programme. Cela s’appelle la compilation 

II va de soi qu’un langage interprets est plus maniable : on peut executer directement son code - et done le 
tester - au fur et a mesure qu’on le tape, sans passer a chaque fois par I’etape supplSmentaire de la compilation. 
Mais il va aussi de soi qu’un programme compile s’exScute beaucoup plus rapidement qu’un programme interprets : 
le gain est couramment d’un facteur 10, voire 20 ou plus. 


Toute application destinee a un usage professionnel (ou meme, tout simplement serieux) est forcement une 
application compilee. 

3. Une logique vicelarde : la programmation recursive 

Vous savez comment sont les informaticiens : on ne peut pas leur donner quoi que ce soit sans qu’ils essayent de 
jouer avec, et le pire, c’est qu’ils y reussissent. 

La programmation des fonctions personnalisees a donne lieu a Lessor d’une logique un peu particuliere, adaptee 
en particular au traitement de certains problemes mathematiques (ou de jeux) : la programmation recursive. Pour 
vous expliquer de quoi il retourne, nous allons reprendre un exemple cher a vos coeurs : le calcul d’une factorielle 
(la, je sentais que j’allais encore me faire des copains). 

Rappelez-vous : la formule de calcul de la factorielle d’un nombre n s’ecrit : 

N ! = 1 x 2 x 3 x ... x n 

Nous avions programme cela aussi sec avec une boucle Pour, et roule Raoul. Mais une autre maniere de voir les 
choses, ni plus juste, ni moins juste, serait de dire que quel que soit le nombre n : 

n ! = n x (n-1 ) ! 

En bon francais : la factorielle d’un nombre, c’est ce nombre multiplie par la factorielle du nombre precedent. 
Encore une fois, c’est une maniere ni plus juste ni moins juste de presenter les choses ; c’est simplement une 
maniere differente. 

Si I’on doit programmer cela, on peut alors imaginer une fonction Fact, chargee de calculer la factorielle. Cette 
fonction effectue la multiplication du nombre passe en argument par la factorielle du nombre precedent. Et cette 
factorielle du nombre precedent va bien entendu etre elle-meme calculee par la fonction Fact. 

Autrement dit, on va creer une fonction qui pour fournir son resultat, va s’appeler elle-meme un certain 
nombre de fois. C’est cela, la recursivite. 

Toutefois, il nous manque une chose pour finir : quand ces auto-appels de la fonction Fact vont-ils s’arreter ? 
Cela n’aura-t-il done jamais de fin ? Si, bien sur, rassure-toi, 6 public, la recursivite, ce n’est pas Les Feux de 
L’Amour. On s’arrete quand on arrive au nombre 1, pour lequel la factorielle est par definition 1. 

Cela produit I’ecriture suivante, un peu deconcertante certes, mais parfois tres pratique : 

Fonction Fact (n en Numerique) 
si n = 0 alors 
Renvoyer 1 
si non 

Renvoyer Fact(N-l) * N 
Finsi 

Fin Fonction 

Vous remarquerez que le processus recursif remplace en quelque sorte la boucle, e’est-a-dire un processus 
iteratif. Et en plus, avec tous ces nouveaux mots qui riment, vous allez pouvoir ecrire de tres chouettes poemes. 
Vous remarquerez aussi qu’on traite le probleme a I’envers : on part du nombre, et on remonte a rebours jusqu’a 1 
pour pouvoir calculer la factorielle. Cet effet de rebours est caracteristique de la programmation recursive. 

Pour conclure sur la recursivite, trois remarques fondamentales. 

© 

• la programmation recursive, pour traiter certains problemes, est tres economique pour le 
programmeur ; elle permet de faire les choses correctement, en tres peu destructions. 

• en revanche, elle est tres dispendieuse de ressources machine. Car a I’execution, la machine va 
etre obligee de creer autant de variables temporaires que de « tours » de fonction en attente. 

• Last but not least, et c’est le gag final, tout probleme formule en termes recursifs peut 
egalement etre formule en termes iteratifs ! Done, si la programmation recursive peut faciliter la vie du 
programmeur, elle n’est jamais indispensable. Mais ca me faisait tant plaisir de vous en parler que je n’ai 
pas pu resister... Et puis, accessoirement, meme si on ne s'en sert pas, en tant qu'informaticien, il faut 
connaitre cette technique sur laquelle on peut toujours tomber un jour ou Lautre. 


